Lessons Learned from Hyper-V Replica

Hyper-V Replica
Hyper-V Replica

Windows Server 2012 introduced a boatload of new features, but my favorite feature has to be Hyper-V 3.0. Microsoft dramatically revamped its hyper visor since Windows Server 2008 R2 bringing all sorts of reliability, performance, and scalability to the product. Finally it was a hypervisor of which I could be proud. Hyper-V Replica was a feature introduced with Hyper-V 3.0 giving us the ability to replicate selectable VHD(X)’s of VM’s to other Hyper-V hosts or clusters. Hyper-V Replica could now become the basis of a disaster recovery solution adequate for most small to medium size businesses. Windows Server 2012 R2 brought additional replication frequency schedules as well as extended replica allowing you to replicate the VM to a third location.

One thing I found with Hyper-V Replica is that you do have to monitor the replication health of your VMs. Sometimes busy patching windows, extended maintenance, or even certain backup applications can cause the replication to become unhealthy. In some cases simply resuming the replication resolves the issue while other VMs require a resynchronization. (Resynchronization requires additional CPU and network overhead which may be best to be run after business hours.) In some cases we had to move the VM to another node on the cluster to get the replication to resume.

To monitor the Hyper-V Replica I wrote a PowerShell tool to check and monitor the health of VM replication.

Check-HyperVReplica is a PowerShell script designed to work as a Nagios plugin that will get the replication health of all the VM’s on a Hyper-V host and output the status to be consumed by a Nagios server. However the script can be used in a standalone way as shown in the example below. Instructions for using the script along with how to incorporate it into your Nagios/NSClient++ environment are provided in the comment-based help.


What lessons have you learned from deploying Hyper-V Replica?