Performing a Hyper-V Replica Test Failover

In this post I will explain how you can use the test failover functionality of Hyper-V Replica to evaluate the infrastructural elements of implementing a business continuity plan (BCP).

What Is a Test Failover?

Just like a backup, your disaster recovery (DR) business continuity plan needs to be tested. And just as with a test backup, you need to be able to test the technology elements, namely starting up the replica virtual machines and therefore their services, without any impact on running production systems and the operations of the business.
Hyper-V Replica has a built-in feature called a test failover that allows you to start up linked clones of your offline replica virtual machines on a selected virtual network (probably isolated) without impacting your production systems. These test virtual machines can be created very quickly, started up, used, and destroyed, making the technical elements of your BCP test very easy.
There also is a nice unintended scenario with test failovers: You can use this feature to not only test your BCP, but also to bring online a copy of production systems for testing and diagnostics. Maybe engineers need to test OS or service upgrades and document upgrade/rollback plans? Maybe service administrators or operators need to diagnose performance or health issues? A test failover allows you to bring online a clone of production systems for a realistic and isolated test lab.

How a Test Failover Works

There are two elements to the test failover. There is a test virtual switch on the replica host to allow the test virtual machine to have network connectivity but remain isolated from production services in the primary site.
The second element is creating the test replica virtual machine. This creates a clone of the replica virtual machine. The machine configuration is identical except for:

• Network connectivity: The virtual NIC will be connected to the pre-designated test virtual switch.
• Virtual hard disks: Instead of slowly copying the virtual hard disks, differential disks are created and linked to the virtual hard disks of the replica VMs, working similarly to a checkpoint (or Hyper-V snapshot). This allows the test VM to be created quickly and use the disk contents of the replica VM as a starting point. The parent virtual hard disks are read from and newer data is written to and read from the differential virtual hard disks.

How a test failover works using a linked-clone process.

Implement a Test Failover in Hyper-V Replica

The first step is to prepare the networking for a test failover.

• Create one or more isolated virtual switches: These networks will be used to bring your test failover VMs online without causing address, name, or service conflicts with production systems. Create these networks on the hosts in the secondary site where you will perform the test failover.
• Assign VMs to isolated virtual switches: Configure the connection of the virtual network in the replica VM for test purposes by expanding the properties of the VM’s virtual NIC, browsing to test failover and selecting the test failover virtual switch under Virtual Switch.

Not only is this approach quick to start up, but it also means that replication will continue uninterrupted – we wouldn’t want Mr. Murphy to cause a disaster during a BCP test and leave us hanging!

Configuring a virtual switch for test failover.

• Select the replica virtual machine you want to test in Hyper-V Recovery Manager (or Failover Cluster Manager) and select Replication > Test Failover. A window will pop up asking you which recovery point (historical copy) of the VM should be used for the failover. Only one option (the latest version) of the VM will be available if you didn’t enable historical copies.

The test failover VM is created with a suffix of “- Test.” You can power up and use the cloned virtual machine, testing that services will be operational and data will be available. Note that this VM will use any configured failover IP address that is configured in the replica VM’s NIC properties. The replica VM will remain offline and accept replication changes from the primary site.

• After the test, right-click on the replica VM (not the test VM) and select Replication > Stop Test Failover. The test VM will be destroyed without impacting the replica VM.

FAQs

How long does it take to set up Hyper V Replication Failover for multiple virtual machines?

The initial Hyper V Replication Failover setup typically takes 30-60 minutes per virtual machine, depending on the size of the VM and network bandwidth. For multiple VMs, it’s recommended to schedule the initial replication during off-peak hours to minimize network impact.

What are the minimum bandwidth requirements for Hyper V Replication Failover to work effectively?

For Hyper V Replication Failover to function optimally, a minimum bandwidth of 5 Mbps is recommended for each actively replicating VM. However, the actual requirement depends on the rate of data change and replication frequency settings.

Can Hyper V Replication Failover work across different Windows Server versions?

Hyper V Replication Failover supports cross-version replication between Windows Server 2016, 2019, and 2022, but you can’t replicate from a newer version to an older one. Always ensure the destination server runs the same or newer version than the source.

What happens to Hyper V Replication Failover during planned maintenance windows?

During planned maintenance, Hyper V Replication Failover can be temporarily paused without losing synchronization. Once resumed, it will automatically catch up with any changes made during the maintenance period, ensuring data consistency.

Does Hyper V Replication Failover support encrypted virtual machines?

Yes, Hyper V Replication Failover fully supports encrypted VMs, but both the source and destination hosts must have the appropriate encryption certificates installed and configured. The replication process maintains encryption throughout the transfer.