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 recovery group and then add it back.
For VMware destinations, replication is not supported with user-created checkpoints on the source Hyper-V VM.
Azure Stack Hub Considerations
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 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.
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.
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 -NRun the following command to verify that Hyper-V drivers are present in the boot image:
lsinitrd | grep hvVerify that no dracut conf files (for example, /usr/lib/dracut/dracut.conf.d/01-dist.conf) contain the following line:
hostonly="yes"Run a new replication operation.
For more information, see Prepare a CentOS-based virtual machine for 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. This requires a storage account for replication and failback operations.
For Windows VMs, to enable disks to be brought online as part of the conversion, enable SAN policy for the source VM. You can use this workaround for disks that are not shared.
Open a command line or PowerShell session locally on the VM.
Open the disk partition tool:
C:> diskpartVerify that the SAN policy is set to Offline Shared:
DISKPART> SAN
SAN Policy : Offline SharedChange the policy to OnlineAll:
DISKPART> SAN POLICY=OnlineAll
You must have either an Azure Standard or Premium general-purpose storage account.
Define one or more resource groups for the application that is associated with the Azure Stack Hub virtualization client.
Replication is not supported for virtual machines that use Extensible Firmware Interface (EFI) boot methods. A VM that has EFI boot enabled can be replicated as an Azure Stack Hub VM, but the resulting VM is not bootable. For successful conversion results, the source VM must boot using BIOS, because Azure Stack Hub does not support Unified Extensible Firmware Interface (UEFI) or EFI boot methods. The OS volume must use MBR partitioning rather than GPT.
The VM name can contain only alphanumeric characters and the '-' character. The name cannot contain any Unicode Transformation Format (UTF) characters.
For managed disks replication, you can select the disk type of the Azure Stack Hub destination VM. This is useful in managing storage and costs in your environment.
Consider the following:
When the Disk Type for the recovery target is set to Auto select, the destination VM disk type is as follows:
For Azure Stack Hub to Azure Stack Hub replication, the destination VM disk type is the same as the source VM.
For VMware to Azure Stack Hub replication, the destination VM disk type is standard HDD.
When the Disk Type for the recovery target is set to Premium SSD, but in the Recovery Group Override window, the Disk Type is set to Original, the destination VM disk type is as follows:
For Azure Stack Hub to Azure Stack Hub replication, the destination VM disk type is the same as the source VM.
When the Disk Type for the recovery target is set to Auto select, and in the Recovery Group Override window, the Disk Type is set to Original, the destination VM disk type is as follows:
For Azure Stack Hub to Azure Stack Hub replication, when in the Recovery Group Override window, the VM size selected does not support premium SSD (for example, D2v3), the destination VM disk type is standard HDD.
For Azure Stack Hub to Azure Stack Hub replication, when in the Recovery Group Override window, the VM size selected supports premium SSD (for example, B2ms), the destination VM disk type is the same as the source VM.