Most hypervisor clusters are based around the use of shared storage, meaning that each node in the failover cluster is connected to the same storage mechanism. During a failover situation in which a node fails and another node takes over the operation of virtual machines, the VMs won't lose access to virtual hard drive files because those files are kept in the shared storage. Using shared storage works really well for clustering, but it has a fatal flaw. If the cluster shared volume becomes corrupted, then the problem will affect every node in the cluster.
Hyper-V Replicas, on the other hand, do not use shared storage. Each replica has its own copy of any virtual hard disks or virtual machine components that have been replicated. That being the case, replicas are often used as a backup supplement. A replica virtual machine can be started and used even if the primary virtual machine copy (or even the entire failover cluster) has failed. It is even possible to roll back a replica to an earlier point in time by using snapshots.
As you can see, there are obvious benefits to using replicas. Like any other backup-oriented solution, however, testing is critical. You never want to find yourself in a situation where it becomes necessary to use (or extract data from) a replica, only to discover that a problem has rendered the replica useless. Fortunately, it is relatively easy to test your replicas.
Before I show you how to test a virtual machine replica, I need to point out that there is an ongoing synchronization process that keeps track of changes made to the primary virtual machine copy and writes those changes to the replica. The synchronization process does not occur in real time. Instead, synchronizations are scheduled. By default, the synchronization process occurs every five minutes.
Fortunately, Hyper-V Replica testing does not negatively affect the synchronization process. When you initiate a test, the hypervisor creates an entirely separate virtual machine that can be used for testing purposes. This approach yields two benefits. First, it allows administrators to interact with the test VM without the fear of accidentally modifying their replica VM. Second, it allows the synchronization process to continue as normal without being affected by the tests.
In spite of its name, replica failover testing does not test the hypervisor's failover capabilities. Instead, it gives you the chance to make sure that the replica is healthy, up to date and, most important, that you can mount and use the replica. To test the replica, open the Hyper-V Manager on the host server containing the replica, right click on the replica and choose the Replication | Test Failover commands from the shortcut menus, as shown in Figure A.
At this point, you will see a message similar to the one shown in Figure B, asking you to select a recovery point from which to create the test virtual machine. The test virtual machine creation process is based on the use of snapshots. As such, the hypervisor does not need to create a copy of the replica for testing purposes.
Select the recovery point on which you want to base the failover tests and then click the Test Failover button. Figure C shows that the hypervisor will create a new virtual machine with the word Test appended to the virtual machine name. You can also see in the figure that a virtual machine snapshot was created to facilitate the testing process.
One important thing to know about the test VM is that by default it is not connected to a virtual switch. This keeps the test VM from interfering with the production VM on which the replica was based. Aside from the absence of network connectivity, the test VM should be identical to your production VM. You can start the test VM, log into it and make sure that it functions properly.
When you have finished using the test VM, shut it down and then right click on the replica VM (not the test VM) and choose the Replication | Stop Test Failover commands from the shortcut menu, as shown in Figure D.
When you stop the failover testing, the test virtual machine is deleted and the snapshot that was created on the replica VM is also removed. At this point, everything should be back to normal. You can verify that the replication process has been unaffected by clicking on the Replication tab at the bottom of the console and verifying that Replication Health indicates a status of Normal, as shown in Figure E.
About the author:
Brien M. Posey, MCSE, has received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server. Brien has served as CIO for a nationwide chain of hospitals and has been responsible for the department of information management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.
This was first published in July 2013