Author name: Managecast Technologies

Symptoms After starting a SureBackup job, it stops almost immediately with the following error: Error: No host is compatible with the virtual machine. When a host leaves Maintenance Mode, is patched, or experiences a temporary issue (i.e., outages, hiccups), the powered off virtual lab can lose its “home” host. From vCenter’s point of view, the VM now sits inside the vApp folder but is orphaned—no ESXi host currently owns it. The moment Veeam asks vCenter to start the appliance, the placement engine evaluates every host in the cluster, finds no valid target, and throws the “No host is compatible” fault. Quick Fix  In your vCenter:  SureBackup’s “No host is compatible”, in most cases, is simply an orphaned lab appliance. A quick migration—even to the same host—will help associate the virtual lab with the host and fix this error. For further assistance, contact our support team at support@managecast.com. 

Introduction When using CDP and attempting to complete the initial sync for a virtual machine, the initial sync may complete with the following error: The initial sync process for CDP is when it copies all of the data for a virtual machine from the client side to the target side, creating a working replica of the VM as an initial “restore point”.  This restore point is basically a working VM replica on the target size that can be used in a failover situation to boot the VM.  Once the initial sync has completed, the status for that VM should then go to “syncing”, which means CDP is now synchronizing incremental changes in the VM. The Issue Sometimes after the initial sync completes, the VM synchronization process may go into a failed state with the following error: The most common issue with this is a backup or replication job that has taken place during the CDP initial sync process that took a snapshot of the VM.  During the CDP initial sync process, no snapshots of the VM can exist or be taken from any source, this includes any Veeam or VMware tasks that take snapshots or any pre-existing snapshot of the VM. Per Veeam’s documentation: https://helpcenter.veeam.com/docs/backup/vsphere/cdp_requirements.html?ver=120 “VMs that you plan to protect must not have snapshots at the moment the CDP policy starts for the first time.” If a snapshot is taken while the CDP initial sync is taking place, CDP doesn’t just fail (even though it’s not going to work anyway), CDP continues to try to complete the process, but now it’s in a perpetual behind state because of the snapshot and the sync process runs much slower.  Then each time the backups with snapshots runs again and again, which has a cumulative slowness effect on CDP, so it just gets slower and slower to a crawl, then when it finally copies everything at the end, it is so far behind it can never catch up, so it then has a perpetual disk traffic not clean. Solution Verify no snapshots exist when the VM’s initial sync process is taking place and confirm that no other jobs or policies will run that may create a snapshot of that VM.  If a VM was replicated and is now in a failed state, that replica must be deleted from the “Replicas” section before attempting to start the CDP sync again. Conclusion As part of the initial sync process, CDP attempts to make a replica of the VM on the target side, which is basically a one-to-one copy of the existing VM.  When a snapshot is taken on the source side, the VM’s disk is placed in a read-only state and a delta file is created to record all of the changes.  This changes the disk’s state, thus the I/O flow that CDP is monitoring is disrupted, and CDP cannot continue to accurately track and replicate the changes since the I/O flow has now changed.  Furthermore, the target replica doesn’t detect these changes immediately, resulting in a mismatch between the source and destination size.  Veeam now tries to restart the process but ends up in basically a failed loop state.

The “Job aborted due to server termination” error in Veeam occurs when the backup job is unexpectedly interrupted due to the backup server shutting down or restarting. This can be caused by scheduled system updates, maintenance tasks, or resource constraints that force the server to reboot during an active backup operation.  Suggested Solution  To prevent this issue, review and adjust scheduled tasks and updates that may cause the server to restart during backup jobs:  By proactively managing scheduled tasks, updates, and system settings, you can prevent unexpected server terminations and ensure uninterrupted Veeam backup operations.   For more information, please contact our support team at support@managecast.com. 

Veeam’s malware detection feature scans backups for potential threats before they are restored or used in production. Once a scan completes, the metadata should be published to the Veeam Guest Catalog Service, which stores backup indexing and security scan results.  When this process fails, users may see the “Failed to publish malware detection metadata to the catalog” warning in their job logs.  This warning may occur due to:  Steps to Resolve the Issue  Restart the Veeam Guest Catalog Service  Simply restarting this service may help resolve the issue.  To restart it:  Check File Permissions on the Catalog Folder  Ensure that the Veeam Backup Service account has full control over:  C:\ProgramData\Veeam\Backup\Catalog  C:\Program Files\Veeam\Backup and Replication\Catalog  While this issue is not severe, it can still be a concern for administrators who prioritize security and rely on Veeam’s malware scanning. If the issue persists, please contact our support team at support@managecast.com for further investigation.