Hyper-V Replica in depth
by Mike Resseler
Fill in the form to download

Planned failover

A planned failover is something that you perform when you know in advance you are going to need a failover. This could be a hurricane coming your way and you want to be proactive, or maybe you just need to do some maintenance on the primary server. The nice thing about this failover type is that you won’t have noticeable downtime or data loss, so this procedure can also be used as a test of your disaster recovery procedures (note that this can be done with Test Failover as well).

Follow this procedure:

Shut down the production VM. Planned failover will give you an error notification when it is still running. You do need to do this manually since the wizard won’t do it for you.

Right-click on the production VM that runs on the primary server and choose Planned Failover...as shown in Figure 22.

Starting your planned failover
Figure 22: Starting your planned failover

By default, the checkbox for Reverse the replication direction after failover is not selected. It is advised to select this checkbox as shown in Figure 23, so that the production VM will receive the changes back with no data loss when the planned failover procedure is finished. One note of caution here: At that moment, the primary server also becomes a replica server, so the host must be configured to allow replication (see the section on enabling a host as replica server).

Figure 23: Failover

You will see the planned failover happening (Figure 24) and if all goes well, you will finally get a message that the failover has succeeded. At that time, the replica VM is running rather than the production VM.

Planned Failover
Figure 24: Planned Failover

A few words of caution are needed here. If you have configured alternative network settings, then they are working now. Imagine that your replica VMs are in another data center and you are not using stretched VLANs—at that moment your network config probably is different. That also means that you need to redirect your users who connect to that server accordingly. DNS updates are not done automatically by the planned failover wizard, so it might be that additional manual work is needed from your side.

And of course, you can do this entirely by using PowerShell.

On the primary[1] server (“core” is the name of my VM):

$PrimaryVM1 = “Core”
Stop-VM $PrimaryVM1
Start-VMFailover -VMName $PrimaryVM1 –prepare

Then jump to the replica server:

$ReplicaVM1 = “Core”
Start-VMFailover -VMName $ReplicaVM1
Start-VM $ReplicaVM1

And finally, when you also want to reverse the replication:

Set-VMReplication -reverse -VMName $ReplicaVM1

The replica VM up and running, there is no data loss and we have reversed the direction. Now let’s assume that whatever happened or needed to happen at the primary server is done, and we want to start the procedure again. To be able to do that, we are going to perform another planned failover, but this time it will start from the replica server. So we will shut down the VM again (downtime!) and follow the same procedure as above.

The failover will happen again, and you will reverse the replication back to your starting point (see Figure 25).

Going back to the original situation
Figure 25: Going back to the original situation

If you are using extended replication, note that you will have more options here. In this example, you can fail over from A to B and reverse the replication to A. But in an A,B,C scenario, you might want to fail over to B and use C as the new replica or fail over completely to C—all new scenarios that you can use.

[1] When this is done on a failover cluster, these PowerShell commands should be run against the server that is the current owner of that VM

Mike Resseler
About the author
Mike Resseler is a Product Strategy Specialist for Veeam. Mike is focused on technologies around Hyper-V and System Center. With years of experience in the field, he presents on many occasions at large events such as MMS, TechEd and TechDays. Mike has been awarded the MVP for System Center Cloud and Datacenter Management since 2010. His major hobby is discussing and developing solid disaster recovery scenarios. Additionally, he has enterprise-class experience in private cloud architecture and deployment, with marked focus on protection from the bottom to the top. He holds certifications in many Microsoft Technologies such as MCITP.