Considerations for Azure Replication

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

General Considerations

• During a replication operation, you can modify destination network settings only for Windows VMs. Linux VMs are replicated without network connections.

• 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, the VM is not replicated. This situation can occur when a VM with the same name is added on the hypervisor for the source VM. To resolve the issue, remove the VM from the replication group and then add it back.

• For VMware destinations, replication is not supported with user-created checkpoints on the source Hyper-V VM.

Azure Considerations

• Before you auto recover a VM from a non-Azure hypervisor, 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 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.

• The operating system for the destination VM must be an operating system that is supported for Azure.

• You can replicate VMs that use BitLocker in the guest OS.

• Before you replicate 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 in order to boot the VM after replication operations.

  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:

     hostonly="yes"

  6. Run a new replication operation.

     For more information, see Prepare Linux for Imaging in Azure on the Microsoft documentation website.

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

• Virtual machines (VMs) with encrypted blobs can be protected and fully recovered. However, guest file recovery of these VMs is not currently supported.

• If a virtual machine is encrypted using Azure Key Vault:

  • Full VM restores are supported per source subscription. However, restores of encrypted VMs to a different subscription are not supported due to an Azure limitation with restoring Key Vault across subscriptions.

  • Restoring to a different region under the same subscription will create a new key vault automatically, and the restore job will complete successfully.

  • Keys and secrets are not accessible to subscription users by default when the Key Vault itself is restored. The restore operation will add only the application's service principal in the Key Vault access control as an authorized user. If necessary, the subscription administrator can make changes to these permissions using the Azure portal.

  • Microsoft restrictions for VMs that are encrypted using Azure Key Vault effect backup and restore capabilities in the Commvault Cloud software. For more information, see Azure Key Vault.

  • For VMs encrypted with customer-managed encryption keys, full VM restores complete successfully; however, for full VM restores from streaming backups, the customer-managed encryption key settings or disk encryption sets (DES) are not applied to the destination VM. You must manually apply the DES settings to the destination VM.

• During Azure to Azure replication operations, the tags that are set at the VM, disk, and network interface level are preserved.