Information and announcements from Program Managers, Product Managers, Developers and Testers in the Microsoft Virtualization team.
If you are wondering “I have enabled replication and it looks like everything is in progress, but how do I know that I am truly protected”, then keep reading the next few posts as we walk you through the various types of failover, how and when to use them and the gotchas in different deployments.
At a high level, Hyper-V Replica supports three types of Failover:
Each of these is built to meet specific and different needs. As you might know by now, using Hyper-V Replica you can replicate between different primary and replica site deployments – your primary server could be a standalone server or part of a cluster and similarly your replica server could be a standalone server or part of a cluster. Independent of your deployment, the workflow and the set of features offered are the same and the 3 types of failovers work in all deployments.
For this article, let’s assume the name of the virtual machine is VirtualMachine_Workload.
Test Failover is an operation initiated on your replica virtual machine which allows you to test the sanity of the virtualized workload without interrupting your production workload or ongoing replication.
Think of Test Failover as an ability to non-disruptively simulate your recovery procedure in an isolated network. You should initiate this operation if you wish to:
TFO is performed on the replica virtual machine by right-clicking on the VM and choosing the Test Failover operation (either from the Hyper-V Manager or from the Failover Clustering Manager)
You are given a choice to pick one of the available recovery points.
After this, a NEW virtual machine is spun up on the replica site. The name of the new virtual machine is the name of the replica virtual machine with “ - Test” appended. In our example, it would be VirtualMachine_Workload – Test
The TFO virtual machine should then be started in an isolated network and client tests can be run against the same to validate replication. You can pre-assign a network and an IP address using the guest IP address injection feature. Once satisfied that replication is kosher, you should do “Stop Test Failover” on the Replica virtual machine, which will clean up the duplicate virtual machine.
Since Test Failover does NOT impact your production workload and does NOT impact your ongoing replication, it is recommended that you perform TFO regularly. There are a couple of mechanisms which help you track the frequency of this event – BPA rules and replication health.
The above procedure can be achieved using Powershell using the following cmdlets.
The next post will cover Planned Failover and the last in the series will cover the Unplanned Failover.
<p>i am hyper-v lover .. you write a nice aricle.. thanks</p>
<p>Thanks for the article how do you license Hyper-V replica ? </p>
<p>To Greg - I will post the licensing FAQ link shortly. </p>
Do we have the license FAQ finalized? We always get this question from customers when they want to implement HYPER-V replica on the DR site.
Thank you for this very needed document!<br/><br/>Only one question: <br/>What you mean "Test Failover is an operation initiated on your replica virtual machine" ?<br/>Is it the "Primary" or the "Spare" VM?<br/><br/>For example, we have two servers: Server1 and Server2. Server1 is active and Server2 as a spare/replica sever.<br/>So, we need to iitiate the Test Failover on Server2?<br/><br/>Regards,<br/>Vi
Sorry, no need to answer my question, <br/>I have read 'Planned and unplanned Failover' and I have understood what was meant as 'on Replica machine'.<br/><br/>Thank you very much for such a useful work!<br/><br/><br/>Regards,<br/>Vi