Information and announcements from Program Managers, Product Managers, Developers and Testers in the Microsoft Virtualization team.
Hyper-V Replica provides three methods to do initial replication:
Each option for initial replication has a specific scenario for which it excels. In this post we will dive into the underlying reasons for including option 3 in Hyper-V Replica, the scenarios where it is advantageous, and cover its usage. This blog post is co-authored by Shivam Garg, Senior Program Manager Lead.
This method of initial replication is rather self-explanatory – it takes an existing VM on the replica site as the baseline to be synced with the primary. However, it’s not enough to pick any virtual machine on the replica site to use as an initial copy. Hyper-V Replica places certain requirements on the VM that can be used in this method of initial replication:
Given the restrictions placed on the existing VM that can act as an initial copy, there are a few clear ways to get such a VM:
Although there is a complete VM on the replica side, the Replica VM lags behind the primary VM in terms of the freshness of the data. So as a part of the initial replication process the two VMs have to be brought into sync. This process is very similar to resynchronization and is very IOPS intensive. Depending on the differences between the primary and Replica VHDs, there could also be significant network traffic to transfer the delta changes from the primary site to the replica site.
The biggest advantage that comes from using an existing VM is that the VHDs are already present on the replica site. But this is also based on the assumption that most of the data is already present in those VHDs. For example, when restoring the VM from backup, the backup copy would be a few hours behind the primary… perhaps a day behind. The assumption is that the delta changes [between the restored VM and the current primary VM] are small enough to be sent over the network. Thus the data difference between the primary VHDs and Replica VHDs should not be too large – otherwise Online IR would be more efficient from an IOPS perspective.
We also need to consider the size of the VHDs. If the primary VM has large VHDs then Online IR might not be preferred to begin with, and OOB IR would be used for initial replication. However, if the set of delta changes that can be sent over the network is small enough then this method could be quicker than OOB IR as well. Thus if the data difference between the primary VHDs and Replica VHDs is large and the VHDs are also large, then it might be simpler to use OOB IR. With large VHDs and a large data difference between primary and Replica VHDs, this replication method will consume a large number of IOPS and choke the network.
Thus a replication scenario that involves (1) large VHDs that to be replicated and (2) a smaller set of delta changes for syncing [when compared to the size of the VHDs] will be an attractive option for using an existing virtual machine for initial replication.
Using this option through the UI is extremely simple – you simply need to select the option with “Use an existing virtual machine on the Replica server as the initial copy”. This option is presented to you during the Enable Replication wizard.
When using PowerShell, there is a sequence of 3 commands that need to be executed:
PS C:\> Enable-VMReplication -ComputerName replica.contoso.com -VMName Test-VM -AsReplica
PS C:\> Enable-VMReplication -ComputerName primary.contoso.com -VMName Test-VM -ReplicaServerName replica.contoso.com -ReplicaServerPort 80 -AuthenticationType Kerberos
PS C:\> Start-VMInitialReplication -ComputerName primary.contoso.com -VMName Test-VM -UseBackup
The –UseBackup option in the Start-VMInitialReplication commandlet is the one that indicates the use of an existing VM on the replica site for the purposes of initial replication.
As with the other methods of initial replication, you can also schedule when the initial replication process occurs.
If the Replica VM is on a cluster, ensure that it is made Highly Available (HA) before any further actions are taken. This is a prerequisite and it enables the VM to be picked up by the Failover Cluster service – and consequently by the Hyper-V Replica Broker.
Failing to do so will throw errors similar to this (Event ID 29410):
Cannot perform the requested Hyper-V Replica operation for virtual machine 'Test-VM' because the virtual machine is not highly available. Make virtual machine highly available using Microsoft Failover Cluster Manager and try again. (Virtual machine ID 6DDC63C1-0135-40CA-B998-A606D91080E9)
Also, the replica server used in the commandlets and the UI will be the name of the Hyper-V Replica Broker instance in the cluster (Note: setting the VM AsReplica has to be done with the actual replica host and not the broker on the replica site).
PS C:\> Enable-VMReplication -ComputerName replicahost.contoso.com -VMName Test-VM –AsReplica
PS C:\> Enable-VMReplication -ComputerName primary.contoso.com -VMName Test-VM -ReplicaServerName replicabroker.contoso.com -ReplicaServerPort 80 -AuthenticationType Kerberos
PS C:\> Start-VMInitialReplication -ComputerName primary.contoso.com -VMName Test-VM –UseBackup
Which initial replication method do you use on your setup? We would be interested in hearing your feedback!
Thanks for the info, I was working with this configuration and your post is the first was help me.
Its working fine for me.
Thank very much Mr. Ramdas.