Hyper-V Replica requires only two or three servers with the Hyper-V role installed and a network connection. You will need Windows Server 2016 that has the Hyper-V role enabled. However, when working with Hyper-V Replica you need to think about a few requirements:

In the following tasks, you will see how to prepare and configure three servers to work with Hyper-V Replica and how to enable replication of a virtual machine. The tasks will illustrate setting up the primary server (HVHost01), the replica server (HVHost02), and the extended replica server (HVHost03). At the end of the tasks, you will see how to fail the virtual machine over to in the replica server in case of a disaster.

In Windows Server 2016 Hyper-V, Microsoft has enhanced Hyper-V Replica and added various new features. A brief overview of the enhancements is as follows:

Support for Hot Add/Remove of Disks

For many applications, there is a need to add more disks to scale the application after every few months. In some scenarios, you want to exclude disks as well (for example page file, temp DB, and so on.) sometime after the replication is enabled and you do not want those disks to be replicated anymore.

In the following example, we have added a new virtual hard disk to the VM that was being replicated.

At this point, the VM is still replicating without any error. However, the new disk is not included in the Replica Disks Set as shown in the following screenshot:

In order to add the disk, you need to open Windows PowerShell and run the following command on the primary Hyper-V server:

Please make sure to update $HVHost and $VM variables accordingly.

# Hot Add Disk Hyper-V Replica
$HVHost='HVHost01.demo.local'
$VM='DXB-SQL01' 

Set-VMReplication-ComputerName$HVHost-ReplicatedDisks(Get-VMHardDiskDrive-ComputerName$HVHost-VMName$VM) -VMName$VM 

This script will get all the virtual hard disks for the virtual machine and update the Replicated Disks Set to include the new disk as shown in the following screenshot:

As shown in the next screenshot, the checkpoint is marked as Disk Update Replica.

The VM will resynchronize automatically across the replica host, based on the replication frequency set(30secs, 5min or 15min), and it will resynchronize across the extended replica host as well, based on the replication frequency set (5min or 15min).

Now, if you want to remove a virtual-hard disk from the Replica Disks Set, you have to use the same command discussed earlier, but instead of passing all disks into ReplicatedDisks, you pass in just the disks you want to replicate and leave out the ones you want to remove.

First, you need to find the controller number and controller location before you remove the virtual hard disk by running the following command:

Get-VMReplication-ComputerName$HVHost-VMName$VM-PrimaryServerName$HVHost|select-ExpandPropertyReplicatedDisks

In this example, we need to remove the virtual hard disk that is connected on controller number 1 and controller location 1, as shown in the following screenshot:

To do so, open Windows PowerShell and run the following command on the primary server:

Set-VMReplication-ComputerName$HVHost-ReplicatedDisks(Get-VMHardDiskDrive-ComputerName$HVHost-VMName$VM|Where{$_.ControllerLocation -ne1}) -VMName$VM

This command will get all the disks that are not connected on controller location 1 and update the Replication Disks Set to include only the first two disks.

Hyper-V Replica needs two or three servers to replicate the virtual machine data. The principal server that runs the virtual machines is known as primary server. The secondary server, called replica server is used in case of a failover, and the third server called extended replica server is used in case of a failover as well. The first thing is to enable the replica server in the Hyper-V Settings. The settings are divided in two classes—authentication and authorization. In authentication, there are two options to transfer the virtual machine files over the network—HTTP, which does not encrypt the data and doesn't require any additional configuration and HTTPS, which encrypts the content using digital certificates for authentication. You must request and install an authentication certificate in order to use HTTPS. This option will be covered in the following recipe.

The replica server also needs to be configured to receive data from other servers. That's the role of the authorization part of the window. You can select the option to Allow replication from any authenticated server or specify a list of servers and the path to store the virtual machine files. In the server list, you can also use wildcards, such as *.demo.local to allow any server from the demo.local domain to replicate data to the server. You can use Trusted Groups to separate different areas or customers, creating a sort of tagging. This is an interesting option if you have different customers and want to make sure that their data will be in different storage locations.

Although the primary server does not need these replica server options, it would be a best practice to enable it in the primary servers so that you can use the Planned Failover feature and transfer the VM back to the primary server after an outage.

After this, a firewall exception must be configured to allow Windows Firewall to receive the HTTP (or HTTPS, if you are using the certificates) requests from the primary server. If you configured the primary server as a replica server, you need to run the PowerShell command.

That's basically all you need to set up the host computers with Hyper-V Replica. The next step is to enable the replication on the virtual machine that you want. This is done by selecting the option Enable Replication on the VM.

The first step of the wizard is to select the replica server. After that, you can select the protocol to send the VM files. You can use either HTTP or HTTPS. On the same screen, you can uncheck the option to compress the data over the network. As the primary and replica servers are intended to run on different sites, this option is checked by default. The next option is to select the VHD that needs to be replicated. In case the VM has more than one VHDX, you can select the one VHD that will be present in the replica server. For better performance and to reduce the amount of data that's being replicated, it's recommended to use a different VHDX for the page file within the VM and exclude it from being replicated.

In the Configure Additional Recovery Points window, you can choose to have only the last recovery point of a VM or additional recovery points. You can select the number of recovery points and the interval to create additional recovery points for up to 24 hours. If the applications need to be consistent, then make sure that you use VSS on a set schedule. The last step is to select the initial replication method and schedule for up to a maximum of 12. The default method is to send the initial copy over the network. In case of large virtual machines over slow networks, you can export the VM data to an external media and import in the replica server. In case the VM that you want to replicate already exists in the replica server, you can use it for the initial copy. Then, you can start the replication immediately or schedule the initial replication. It is important to say that the schedule is only applicable during the initial replication. The log replication occurs every 30 seconds, 5 minutes, and 15 minutes and cannot be changed.

When a virtual machine is enabled to replicate, the Hyper-V Replica modules start to monitor the changes in the VHDX and create a log to be replicated. This is done by the change tracking module in the Hyper-V Virtual Storage Stack. The replication starts using an asynchronous method, replaying the log files in reverse order.

Then, the unexpected happens, a disaster occurs. No need to panic (at least with your VMs). Failover isn't automatic. To do so, you must select the virtual machine and fail it over.

In summary, it is extremely important to monitor the health of the replicating VMs. Check the See also section for more details. Hyper-V has inbuilt retry semantics to address transient issues (such as network outage) but there are certain events that require your intervention (for example disk issues). Analyzing the replication health from time to time will help you identify and fix these issues.

When you start designing a Hyper-V Replica deployment, you want to look at the server, storage and network infrastructure which is required to successfully deploy Hyper-V Replica. For this reason, Microsoft released a capacity planning tool to help you fulfill the deployment. The Capacity Planner for Hyper-V Replica provides guidance for server, storage and network provisioning which allow you to successfully plan a Hyper-V Replica deployment. This tool be downloaded from Microsoft download center here: http://www.microsoft.com/download/details.aspx?id=39057

You might be wondering what happens when a virtual machine with a static IP address fails over onto another datacenter with a different subnet and network configuration. For example, on datacenter A, where the primary server sits, you have a VM with IP address, default gateway, DNS settings, and so on. On datacenter B, where the replica server is, there are different network configurations. On datacenter C, where the extended replica server is, there are different network configurations as well, causing problems on all the VMs that failover to access the network.

When the VM starts on the replica or extended replica server, it will lose the network settings. Even if you keep the same network configuration, it will not work because the VM is running on a different network.

Hyper-V Replica allows you to add failover network configuration settings, which can be used when the VM failover onto the replica server. It is also important to note that this requires a synthetic virtual network adapter on the VM and doesn't work with legacy virtual network adapters.

To configure these settings, open the virtual machine settings on the replica or extended replica server, expand the attached network adapter, and click on Failover TCP/IP, as shown in the next screenshot:

You can check the Use the following IPv4 address scheme for the virtual machine option and add the network configuration that you want your VM to use when it fails over the other network.

Please note the same rule for Linux guest OS applies as well. Starting with Windows Server 2012 R2 onwards, Microsoft are tightly integrated with non-Windows OS to provide file-system consistent snapshots and inject IP addresses as part of the failover workflow.

Set-VMReplicationServer -ComputerName HVHost02 -ReplicationEnabled $true -AllowedAuthenticationType Kerberos -ReplicationAllowedFromAnyServer $false -Verbose
New-VMReplicationAuthorizationEntry -ComputerName HVHost02 -AllowedPrimaryServer *.demo.local -ReplicaStorageLocation D:VMs -TrustGroup HVServers -Verbose

Enable-VMReplication -VMName * -ReplicaServerName HVHost02 -ReplicaServerPort 80 -AuthenticationType Kerberos -CompressionEnabled 1 -ReplicationFrequencySec 300 -AutoResynchronizeEnabled 1

Get-VM * -ComputerName HVHost01| ?{$_.ReplicationState -eq "ReadyForInitialReplication"} | Start-VMInitialReplication

Get-Command -Module Hyper-V *Replica*