Considerations for VM Replication

Before you configure replication for virtual machines, consider any restrictions or hypervisor-specific issues that might affect replication operations.

General Considerations

  • If you perform a full backup, the replication operation performs a full replication from the source VM to the destination VM. After the initial creation of destination VMs, synthetic full backups do not affect replication at all.
  • If you select a specific VM for replication, the GUID of the source VM is used to identify the VM for replication. If the GUID of the source VM changes, backups for the VM complete successfully but do not result in a replication job for the VM. This situation can occur when a VM with the same name is added on the hypervisor for the source VM. To resolve this issue, remove the VM from the replication schedule and then add it back.

Hypervisor-Specific Considerations


  • After you perform VM conversion or replication operations to Amazon using the HotAdd method, a Windows instance restarts when a user logs on to the instance for the first time. The restart is required to initialize drivers that are added to the instances during the operation.
  • When you replicate to Amazon, the import method is used if you use a proxy that is not an Amazon instance, if the proxy and destination site are in a different region or zone, or if you do not provide guest credentials for the guest instance.
  • For replication from an Amazon source site to an Amazon destination site, you must use a VSA proxy (access node) that is deployed as an Amazon instance.
  • Each replication job from Amazon to Amazon recreates destination instances completely, even when the replication job is for an incremental backup of a source instance.


  • Before you convert a VM from a non-Azure hypervisor using a "restore as" operation or a Live Sync operation, verify that the source VM meets the requirements for non-endorsed distributions. This verification is important because Linux VMs that are based on an endorsed distribution of Microsoft Azure have the prerequisites that enable them to run on Azure, but VMs that originate from other hypervisors might not. For more information, see Information for Non-Endorsed Distributions.
  • For conversion to Azure or Azure Stack: The operating system for the destination VM must be an operating system that is supported for Microsoft Azure.
  • Before you perform a backup for a Linux source VM that runs CentOS or Red Hat, verify that required Hyper-V drivers are installed on the source VM. Those drivers must be present on the source VM backup in order to boot the VM after conversion.
    1. Enable Changed Block Tracking (CBT) for the source VM.
    2. Take a snapshot of the source VM.
    3. Run the following command to modify the boot image:

      sudo dracut -f -v -N

    4. Run the following command to verify that Hyper-V drivers are present in the boot image:

      lsinitrd | grep hv

    5. Verify that no dracut conf files (for example, /usr/lib/dracut/dracut.conf.d/01-dist.conf) contain the following line:


    6. Run a new backup to use for the conversion.

    For more information, see Prepare a CentOS-based virtual machine for Azure.

  • To replicate VMs to Azure, you must specify a Windows access node (VSA proxy) for the Azure recovery target.

Azure Stack

  • For Red Hat Linux VMs, add required Hyper-V drivers to the VMs before backing up the VMs and replicating the VMs with Live Sync. For more information, see Linux VMs do not boot or are unreachable after Live Sync replication to Azure.
  • If an Azure Stack Hub VM that is used as the source for replication has managed disks, the replication operation converts the disks to unmanaged disks.

    You must identify a storage account for replication and failback operations.


For OpenStack replication, only cinder volumes are replicated at the destination site. The destination instance is deployed only when you perform a failover operation.

Oracle Cloud Infrastructure

For Oracle Cloud Infrastructure, deploy a VSA proxy (access node) in the destination region and in each availability domain where an instance is replicated.


For replicated VMs using source snapshots, failback operations are supported only when replication is configured in the Command Center.

Last modified: 10/28/2020 7:33:16 PM