Maintaining Hyper-V replication health with PowerShell

One of my own personal favorite Hyper-V features is the ability to replicate Hyper-V virtual machines from one host server to another. The one disadvantage to Hyper-V replication, however, is that replicas can, and sometimes do, fall out of sync. When that happens, you may never even know about it unless you are using some sort of notification mechanism that will tell you about your Hyper-V replication health.

Thankfully, Hyper-V replication is far more reliable today than it once was. When Windows Server 2012 R2 was first released, I experienced replication failures on a regular basis. Today, replication failures are rare, but they do occasionally occur. In fact, by pure coincidence, a replication failure actually occurred on one of my Hyper-V hosts while I was writing this article.

Fortunately, it is possible to use PowerShell to keep tabs on the replication process. The Hyper-V module for PowerShell includes a cmdlet called Get-VMReplication that you can use to get an overview of Hyper-V replication. You can see what this cmdlet looks like in action in the figure below.

In this particular case, I only have a single VM that is being replicated, but it is relatively common for organizations to replicate multiple virtual machines. That being the case, it can be useful to filter the cmdlet’s output so that it shows only the desired virtual machines. If for example, I wanted to see a list of virtual machines that were being replicated normally, I could use this command:

Get-VMReplication | Where {$_.Health -eq ‘Normal’}

Conversely, if I wanted to see only those VMs that were in a critical replication state, I could use this command instead:

Get-VMReplication | Where {$_.Health -eq ‘Critical’}

While it’s great to be able to display this sort of information, the command listed above is of limited use by itself. After all, this command only displays replication information for the local machine, and replication makes use of at least two Hyper-V servers. Furthermore, I have seen situations in which one server within a replication pair reports that replication is healthy, while another server reports that replication has failed, so it really is important to check any server that could potentially contain a replicated VM.

The easiest way of checking Hyper-V replication health across all of your hosts is to create a simple PowerShell script. Here is what such a script might look like:

$Hosts = “Prod1″,”Prod2”
ForEach ($Server in $Hosts)
{
$Server
Invoke-Command -ComputerName $Server {Get-VMReplication}

This script begins by creating a variable named $Hosts, which contains the names of the Hyper-V host servers. In this case, my hosts are named Prod1 and Prod2. You would substitute your own hostnames.

Next, the server sets up a loop that will examine each server individually. The loop displays the name of the host, and then runs the Get-VMReplication cmdlet on the host server. The figure below shows the script’s output.

As you look at the figure above, you can see that my Hyper-V replicas are having some problems. So let’s create some code to fix these replication issues.

The cmdlet that is used to restart the replication process is Resume-VMReplication. When using this cmdlet, you have to specify the name of the VM for which you want to resume the replication process. As such, the first thing that we have to do is to modify the code to retrieve the name of the individual VMs that are having replication problems. Here is how I did it:

$Hosts = “Prod1″,”Prod2”
ForEach ($Server in $Hosts)
{
$Server
Invoke-Command -ComputerName $Server {
$FailedReplicas = Get-VMReplication | Where{$_.Health -EQ ‘Critical’}
ForEach ($VM in $FailedReplicas)
{
$VMName = $VM.Name
$VMName
}
}
}

This code is similar to my previous script, except that it uses a nested loop to search for virtual machines whose Hyper-V replication health is in a critical state. From there, the name of the virtual machine is assigned to a variable named $VMName. This script does not actually fix the problem. Instead, it simply outputs the name of the host and the names of any VMs on the host that are having replication problems. Hence, this script is nothing more than a test to make sure that we can retrieve the names of the VMs that are having problems. In the figure below, for example, you can see that the script has identified a problem VM named Mirage on servers named Prod1 and Prod 2.

Now that we have created the basic structure for the script, it is time to modify the script to address any detected Hyper-V replication health issues. To do so, I am going to add one line of code. The line is:

Resume-VMReplication $VMName -Resynchronize

You will notice that I have appended the virtual machine name and the Resynchronize parameter to the Resume-VMReplication cmdlet. The reason why I used this parameter is that without it, the Resume-VMReplication cmdlet assumes that you want to resume from a paused replication cycle. So here is the script in its entirety:

$Hosts = “Prod1″,”Prod2”
ForEach ($Server in $Hosts)
{
$Server
Invoke-Command -ComputerName $Server {
$FailedReplicas = Get-VMReplication | Where{$_.Health -EQ ‘Critical’}
ForEach ($VM in $FailedReplicas)
{
$VMName = $VM.Name
$VMName
Resume-VMReplication $VMName -Resynchronize
}
}
}

The figure below shows what happened when I ran this script on my own system. As you can see, the copy of Mirage (the running VM) on Prod1 is now resynchronizing. However, I received an error saying that the operation cannot be performed on the Prod2 copy (the replica) of Mirage, because the VM is in an unsupported state.

If I switch over to Prod2, however, you can see in the figure below that the Mirage VM is resynchronizing. The reason why I received an error was that by resynchronizing the Prod1 copy of Mirage, the Prod2 replica also began resynchronizing. PowerShell cannot accept a resynchronize request for a VM that is already in the process of resynchronizing, hence the error.

The script that I have created in this article is handy for maintaining Hyper-V replication health. You can further automate the process by using the Windows Task Scheduler to automatically run the script on a daily basis.

Photo credit: Shutterstock