In this post I will quickly demonstrate how to replicate a virtual machine using Hyper-V Replica using Windows Server 2012 (WS2012) or Windows Server 2012 R2 (WS2012 R2). Note that this includes Hyper-V Server. I will return to the topic of Hyper-V Replica in future articles to dive deeper into some of the options.
In this example we will replicate a virtual machine from one non-clustered host to another. We will choose to do the initial copy over the network, and we will use HTTP (Kerberos) authentication. This is the typical configuration you will use in a test or demo lab.
Hyper-V Replica cannot work unless you enable inbound replication on your host or cluster in the secondary site. There you can enable inbound replication from all hosts/clusters that can authentication (not recommended) or you can create a specific policy for each primary site host or cluster (recommended).
In this example are working with non-clustered hosts, so you will open up the Hyper-V Settings of your secondary site host in Hyper-V Manager. Browse to Replication Configuration and configure:
Inbound replication policy.
Tip: Use fully qualified domain names (FQDNs) when entering the name of any host or cluster.
You need to configure the Windows Firewall of the secondary hosts to allow inbound replication. There are two rules; choose the correct one (or both) depending on what authentication protocol (HTTP/HTTPS) you are using, and be sure to modify the port number if you chose a custom port in the Hyper-V Settings:
Make sure that you have end-to-end connectivity though any edge network devices such as firewalls. You can use Test-VMReplicationConnection from a primary site server to verify that the necessary ports are open from a primary site server.
Tip: You should also configure the firewalls on the primary site host/cluster to also allow inbound replication. This is essential if you want to reverse replication of a failed over VM from the secondary site to the primary site.
Choose destination host or cluster.
Authentication Type: Match the method (HTTP or HTTPS) with the type chosen on the destination host or cluster.
Replication protocol and compression.
You will be asked which of the VM’s virtual hard disks you want to replicate. It makes sense to replicate them all, right? But maybe not. You could place the Windows paging file of the VM’s guest OS onto a dedicated virtual hard disk and not replicate this disk. The replica VM will start up and complain after creating a temporary paging file, probably in its system virtual hard disk.
WS2012 Hyper-V will replicate VMs every five minutes. WS2012 R2 gives you an option of every 30 seconds, every 5 minutes, or every 15 minutes. Choose the smallest one that you know that the asynchronous replication can complete within that time frame during peak activity:
Replication frequency on WS2012 R2.
An option with Hyper-V Replica is to maintain hourly-generated snapshots of the replica VM in the DR site. This allows you to failover the VM in the DR site and send it back in time an hour, two hours, and so on, in case data corruption was a part of the disaster you are trying to recover from. WS2012 allows you to maintain up to 15 automatically managed restore points (Hyper-V snapshots) on the secondary site server. WS2012 R2 can manage up to 24 of those checkpoints (Hyper-V snapshots are called “checkpoints” in WS2012). Each checkpoint (or Hyper-V Snapshot) is automatically created every hour, and deletion/merging is done automatically. A sub-option is to create the snapshots using Volume Shadow Copy Service (VSS) snapshots to guarantee application consistency. The Hyper-V team’s testing hasn’t found this to be necessary yet, but the sub-option is there for peace of mind.
Optional recovery points.
The initial copy is done immediately over the network at the end of the wizard by default. This is perfect for a quick demonstration. Alternatively you can:
Perform the initial copy over the network.
The wizard is now complete. Hyper-V Replica will:
Tip: Enable Hyper-V Replica on the primary site host to allow inbound replication from the secondary site host. This will allow reverse replication after a virtual machine has been failed over.
You have a lot of control over the replication of virtual machines: