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

Amazon

After you perform VM conversion or replication operations to Amazon EC2 using the Commvault HotAdd transport mode, 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 AWS VM Import/Export transport mode 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.
Each incremental replication job to AWS reuses the existing destination instance, and only in case of a full replication to AWS, a new destination instance is created.
Note: A new destination instance is created when the primary network interface changes between incremental replication jobs.

Azure and Azure Stack Hub

Before you convert a VM from a non-Azure hypervisor using a "restore as" 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 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 Hub: The operating system for the destination VM must be an operating system that is supported for Azure.
Before you perform a backup for a Linux source VM that runs 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:
```
hostonly="yes"
```
6. Run a new backup to use for the conversion.
To replicate VMs to Azure, you must specify a Windows access node (VSA proxy) for the Azure recovery target.
For managed disks replication, you can select the disk type of the Azure or 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 to Azure or Azure Stack Hub to Azure Stack Hub replication, the destination VM disk type is the same as the source VM.
  - For VMware to Azure or 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 Replication Group Override window, the Disk Type is set to Original, the destination VM disk type is as follows:
  - For Azure to Azure or 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 Replication Group Override window, the Disk Type is set to Original, the destination VM disk type is as follows:
  - For Azure to Azure or Azure Stack Hub to Azure Stack Hub replication, when in the Replication 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 to Azure or Azure Stack Hub to Azure Stack Hub replication, when in the Replication 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.

For Azure Only:

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. 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 VMs that are encrypted using Azure Key Vault effect backup and restore capabilities in the Commvault 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. For more information, see Configuring Disk Encryption Sets on Destination VM.

For Azure Stack Hub Only:

For Red Hat Linux VMs, add required Hyper-V drivers to the VMs before backing up the VMs and replicating the VMs. 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. 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.
1. Open a command line or PowerShell session locally on the VM.
2. Open the disk partition tool:
```
C:> diskpart
```
3. Verify that the SAN policy is set to Offline Shared:
```
DISKPART> SAN
SAN Policy : Offline Shared
```
4. Change 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.

Google Cloud (GCP)

Prepare source VMs for replication.
To back up and restore GCP instances, you must create a GCP service account, and then download the JSON file for GCP service account authentication. You will need this file when you add a GCP hypervisor to your environment.

For more information, see "Create a Google Cloud Service Account" in Configuring Backups for Google Cloud Instances.
The access node must be present on Google Cloud. You can designate one access node to back up instances from multiple projects (to which access rights are provided in your GCP service account). For faster backups and restores, designate at least one access node for every GCP region.

OpenStack

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.

VMware

For replicated VMs using source snapshots, failback operations are supported only when replication is configured in the Command Center.
Periodic replication is not supported for the Cisco HyperFlex and Tintri snap engines.
For VSA snap engine (VVol) replication, the failback operation is a full resync to the source.
Incremental failback resync operations are supported only from streaming VMware backups.