Before you configure replication for virtual machines, consider any restrictions or hypervisor-specific issues that might affect replication operations.
During a replication operation, you can only modify destination network settings 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 this issue, remove the VM from the replication group and then add it back.
Before you replicate 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 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.
The operating system for the destination VM must be an operating system that is supported for Microsoft Azure.
VMs that are encrypted on AWS are created as VMs with no encryption on 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.
Enable Changed Block Tracking (CBT) for the source VM.
Take a snapshot of the source VM.
Run the following command to modify the boot image:
sudo dracut -f -v -N
Run the following command to verify that Hyper-V drivers are present in the boot image:
lsinitrd | grep hv
Verify that no dracut conf files (for example, /usr/lib/dracut/dracut.conf.d/01-dist.conf) contain the following line:
Run a new replication.
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) 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 a Microsoft 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. For more information, see AZR0002: Out of place VM restore to different region might fail when source VM is encrypted.
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 virtual machines encrypted using Azure Key Vault also apply to encrypted Azure virtual machines in your Commcell environment for restoring your virtual machine and Key Vault. 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. For more information, see Configuring Disk Encryption Sets on Destination VM.
During Azure to Azure replication and disaster recovery operations, the tags that are set at the VM, disk, and network interface level are preserved.
During AWS to Azure replication and disaster recovery operations, the tags that are set at the instance and the volume level are preserved.