If you would like to read the other parts in this article series please go to:
- Working With Replicas in Hyper-V 3.0 (Part 1)
- Working With Replicas in Hyper-V 3.0 (Part 2)
- Working With Replicas in Hyper-V 3.0 (Part 3)
- Working With Replicas in Hyper-V 3.0 (Part 4)
- Working With Replicas in Hyper-V 3.0 (Part 6)
Replication Health Testing
As I mentioned in the previous article, you can only perform replication testing on the replica virtual machine. After all, the source virtual machine is presumably a production server. Since the testing process could potentially be disruptive, Microsoft has made it so that you can only test the replica – not the production VM. Besides, the main goal of replica testing is to find out whether or not the replica is healthy enough for a failover, and what better way to accomplish that goal than to test the replica.
If you look at Figure A, you can see what the destination server looks like in my lab. As you can see, I have a single virtual machine named Mirage. The virtual machine is powered off because the virtual machine is a replica. At the bottom of the figure, you can see confirmation that replication is enabled and that the replica is healthy.
Figure A: Replica virtual machines remain powered off unless they are needed.
To perform the failover test, right click on the virtual machine replica and choose the Replication | Test Failover commands from the resulting shortcut menus, as shown in Figure B.
Figure B: To test virtual machine failover, right click on the virtual machine and choose the Replication | Test Failover commands from the resulting shortcut menus.
At this point, you will see a dialog box similar to the one that is shown in Figure C. This dialog box asks you which recovery point you want to base the tests on. Unless you are planning on rolling the virtual machine back to an earlier point in time, you should choose the most recently created recovery point. Once you have made your selection, click the Test Failover button.
Figure C: Choose the recovery point that you want to use and click the Test Failover button.
When you click the Test Failover button, the replica virtual machine’s status (as displayed within the Hyper-V Manager) will change to Test Failover. After about a minute, the status should briefly change to Test Failover – Succeeded. The status indicator will then disappear. When the test completes, you will be left with two virtual machines, as shown in Figure D.
Figure D: The testing process creates a second virtual machine.
The newly created virtual machine (in this case Mirage – Test) exists solely for testing purposes. Before you begin testing the virtual machine however, there is something critically important that you need to know.
Even though Hyper-V has created a test virtual machine, this virtual machine is not as isolated from the replica virtual machine as it might at first appear. The replica virtual machine and the test virtual machine share a virtual hard disk. This means that if you manually delete the test virtual machine and its components then you risk destroying the replica virtual machine in the process. I will show you the proper way to clean things up near the end of this article.
The fact that the replica virtual machine and the test virtual machine share a common virtual hard disk raises a couple of important questions. First, why does Hyper-V even bothers to create a test virtual machine when the test virtual machine uses the replica virtual machine’s virtual hard disks?
Remember that the replica virtual machine is an exact copy of one of your production virtual machines, and the replica virtual machine resides on a host server that is accessible from your production network. If you were to start the replica virtual machine (and there were no safety mechanisms in place to keep you from starting the virtual machine) it would likely cause an IP address conflict. Depending on the virtual machine’s purpose, there might also be application level conflicts that could potentially occur as a result of having two identical virtual machines running on the same network.
Microsoft uses the test virtual machine to solve this problem. As you can see in Figure E, the test virtual machine is not connected to the network. This means that it is safe to start the test virtual machine without having to worry about any resulting network conflicts.
Figure E: The test virtual machine does not have any network connectivity.
So what happens when you start a test virtual machine? Well, as you can see in Figure F, the test virtual machine’s state changes to Running, while the replica virtual machine’s state remains set at Off. You can also see in the figure that it is possible to log into the test virtual machine and interact with it just as you could if you had logged into the production virtual machine (aside from the limits caused by not having network connectivity).
Figure F: You can log into the test virtual machine.
Another thing that you will notice in the figure above is that the Replication tab at the bottom of the screen lists the replication type as Test Replica. The replication state is listed as not enabled, which makes sense when you consider that Hyper-V is configured to replicate data to the replica virtual machine, not to the test virtual machine. As for the main replica virtual machine, replication remains enabled and functional throughout the testing process.
As you will recall, earlier I mentioned that the fact that the replica virtual machine and the test virtual machine share a virtual hard disk raises a couple of questions. However, I only talked about one of those questions. The other question is that of what happens behind the scenes when you start and log into the test virtual machine as we just have.
Believe it or not, signing into the test virtual machine is non disruptive. The replication process continues to work in the background. When the Hyper-V Manager creates the test virtual machine, it snapshots the replica virtual machine. The snapshotting process makes it possible for the replica virtual machine to continue to receive replication updates in spite of the fact that the replica virtual hard disk is in use by the test virtual machine. The snapshotting process also protects the virtual hard disk’s contents against accidental modification.
Of course this means that when you are done testing the replica you will need to let the Hyper-V Manager put everything back into place. To do so, right click on the replica virtual machine and choose the Replication | Stop Test Failover commands from the shortcut menus, as shown in Figure G. When you do, Windows will ask you if you really want to stop the test. Click the Stop Test Failover button to complete the process.
Figure G: Use the Replication | Stop Test Failover commands to conclude the failover tests.
At this point, the Hyper-V Manager will delete the test virtual machine, and will merge the snapshot data so as to bring the replica back to a current state.
Conclusion
As you can see, replication testing is a safe and easy way to make sure that the replica virtual machine is in a functional state. As a best practice, you should always check the replica’s health and perform a failover test prior to performing a planned failover. I plan to conclude the series in Part 6 by talking about planned and unplanned failovers.
If you would like to read the other parts in this article series please go to:
