Windows Server How-To
How To Check Hyper-V Replica Health
Keeping the replicas current will ease the backup process if something goes wrong.
One of the best features in Windows Server 2012 R2 Hyper-V for protecting your virtual machines is the replication feature. The replication feature allows virtual machines (and individual virtual hard disks) to be replicated to a secondary Hyper-V server or to a secondary clustered Hyper-V deployment. If the primary copy of the virtual machine fails catastrophically then the administrator can initiate a failover to the replica in an effort to maintain business continuity.
Hyper-V replicas are kept up to date through an asynchronous replication process. Hyper-V periodically transmits virtual machine updates to replicas. The replication frequency can be set to 30 seconds, five minutes, or fifteen minutes, as shown in Figure 1.
Although the replication process generally works pretty well, it isn't perfect. Sometimes the replication process fails and Hyper-V may eventually quit trying to replicate the virtual machine. As such, it is a good idea to periodically check the replication health and resume the replication process if necessary.
Hyper-V can sometimes be a bit inconsistent in the way that replication health information is reported. As such, there are a few different places that I recommend looking if you really want to know what is going on with a replica.
You should start out by opening the Hyper-V Manager on the server that is running your primary copy of the virtual machine, selecting the virtual machine that you want to check, and then clicking on the Replication tab at the bottom of the window. This tab should tell you the status of the source virtual machine, as shown in Figure 2.
If the replication process is listed as being anything other than healthy, then I recommend right clicking on the virtual machine and selecting the Replication | View Replication Health commands from the shortcut menu. Doing so will provide you with more detailed health information, as shown in Figure 3.
As you look at the figure above, it becomes readily apparent that this particular virtual machine is having some problems. Even so, there are two really important things that you need to know about the information that is being displayed before you attempt to take any sort of corrective action.
The first thing that you need to know is that as previously mentioned, Hyper-V can sometimes show some really inconsistent replication health information. On several occasions I have seen replication health information on the replica server indicate that the replication process is healthy, whereas the server running the primary copy of the virtual machine reports a problem. When the replication process breaks down, the replica server (the destination server) doesn't always figure out that there is a problem right away. Therefore, my advice is to check the primary server and the replica server prior to taking any sort of action. That way, you can make sure that you have a clear understanding of what is really going on.
The other thing that you need to know is that the Replication Health dialog box shown in the previous figure displays historical data. The dialog box may continue to indicate that a problem exists for quite a while after the problem has been fixed. The reason for this is that the data that is displayed refers to replication statistics over about the last 24 hours. Even if you fix a problem, you might still have 23 hours' worth of historical data referencing the problem, so the replication health status can still be listed as critical until all of those missed replication cycles are replaced by new data showing successful replication cycles. If you are in doubt as to the replication health, you can always use the Reset Statistics button to purge the historical data.
So what do you do if you do find a replication health problem? In most cases, you can right click on the VM and choose the Replication | Resume Replication commands from the shortcut menus. Keep in mind that you may have to take corrective action on both the source server and the replica server in order to resolve the problem. In extreme situations, even that might not get the job done. I have seen a few situations in which a replica actually had to be deleted and then recreated in order to resolve a replication health problem.
Brien Posey is a 16-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.