Hyper-V VM replication is a disaster recovery feature that creates a replica of a VM on a remote Hyper-V server and keeps the replica up to date. The VM replica on the remote host is not active, but can be made active should the VM's host fail for some reason.
With Hyper-V replication, the source VM host bundles up any changes in a running VM's VHD file(s) and sends them to the replica server on a regular basis. The replica server then applies those changes to the dormant replica.
Once you have a replica established, you can test the replica to ensure it can start should you need it. Also, you can failover to the replica—bringing the replicated VM up based on the most recently replicated data. If the source VM host becomes inoperable before it can replicate changes on the source VM, there is a risk of those changes being lost.
In this recipe, you create and use a replica of a VM, PSDirect, that you have running on your HV1 server. The recipe sets up the replica on the HV2 server.
This recipe replicates the PSDirect VM running in HV2 to HV1. This assumes you have used the Creating a virtual machine recipe to create the VM, and used the Configuring VM and storage movement recipe; you need to move the PSDirect VM to HV2.
- Configure
HV1andHV2to be trusted for delegation in AD onDC1:$SB1 = { Set-ADComputer -Identity HV1 -TrustedForDelegation $True } Invoke-Command -ComputerName DC1 -ScriptBlock $SB1 $SB2 = { Set-ADComputer -Identity HV2 -TrustedForDelegation $True} Invoke-Command -ComputerName DC1 -ScriptBlock $SB2 - Reboot the
HV1andHV2servers:Restart-Computer -ComputerName HV1 -Force Restart-Computer -ComputerName HV2 -Force
- Once both systems are restarted, log back on to
HV2, and set up both servers as a replication server:$VMRHT = @{ ReplicationEnabled = $true AllowedAuthenticationType = 'Kerberos' KerberosAuthenticationPort = 42000 DefaultStorageLocation = 'C:Replicas' ReplicationAllowedFromAnyServer = $true ComputerName = 'HV1', 'HV2' } Set-VMReplicationServer @VMRHT - Enable
PSDirectonHV2to be a replica source:$VMRHT = @{ VMName = 'PSDirect' Computer = 'HV2' # from server ReplicaServerName = 'HV1' # to server ReplicaServerPort = 42000 AuthenticationType = 'Kerberos' CompressionEnabled = $true RecoveryHistory = 5 } Enable-VMReplication @VMRHT - View the replication status of
HV2:Get-VMReplicationServer -ComputerName HV2
- Check the
PSDirectVM's status onHV2:Get-VM -ComputerName HV2 -VMName PSDirect
- Start the initial replication:
Start-VMInitialReplication -VMName PSDirect -ComputerName HV2
- Examine the initial replication state on
HV1just after you start the initial replication:Measure-VMReplication -ComputerName HV2
- Wait for replication to finish, then examine the replication status on
HV2:Measure-VMReplication -ComputerName HV2
- Test
PSDirectfailover toHV1:$SB = { $VM = Start-VMFailover -AsTest -VMName PSDirect -Confirm:$false Start-VM $VM } Invoke-Command -ComputerName HV1 -ScriptBlock $SB - View the status of VMs on
HV1:Get-VM -ComputerName HV1
- Stop the failover test on
HV1:$SB = { Stop-VMFailover -VMName PSDirect } Invoke-Command -ComputerName HV1 -ScriptBlock $SB - View the status of VMs on
HV1andHV2after failover stopped:Get-VM -ComputerName HV1 Get-VM -ComputerName HV2
- Stop
PSDirectonHV2prior to performing a planned failover:Stop-VM PSDirect -ComputerName HV2
- Start VM failover from
HV1:$STHT = @{ VMName = 'PSDirect' ComputerName = 'HV1' Confirm = $false } Start-VMFailover @STHT - Complete the failover:
$CHT = @{ VMName = 'PSDirect' ComputerName = 'HV1' Confirm = $false } Complete-VMFailover @CHT - Start the replicated VM on
HV1:Start-VM -VMname PSDirect -ComputerName HV1
- View the VMs on
HV1andHV2after the failover:Get-VM -ComputerName HV1 Get-VM -ComputerName HV2
In step 1, you configure HV1 and HV2 to be trusted for delegation in AD on DC1. After configuring delegation, in step 2, you restart both servers to enable the delegation trust. With step 3, you set replication settings, and in step 4, you complete establishing replication between HV2 an HV1. These four steps produce no output.
In step 5, you view the replication status on HV2, which looks like this:
In step 6, you view the VM details of the PSDirect VM, running on HV2, which looks like this:
In step 7, you start the replication of PSDirect from HV2 to HV1. This produces no output. In step 8, just after you started replication, you take another look at the replication status, which looks like this:
After the VM replication has completed, in step 9, you re-check the replication status, which looks like this:
In step 10, you test a failover of PSDirect between the Hyper-V servers. This step produces no output. In step 11, you view the status of the failover test on HV1, which looks like this:
In step 12, you stop the failover test, which produces no output. In step 13, you view the status of VMs on both HV1 and HV2, which looks like this:
In step 14, you shut down the PSDirect VM on HV2 in preparation for a failover. In step 15, you begin the failover. In step 16, you complete the failover. After the VM failover has completed, in step 17, you start the PSDirect VM on HV1. These three steps produce no output. The result of these four steps, which produce no output, is that the PSDirect VM is now running on HV1. You can view this in step 18, where you review the VMs running on both Hyper-V servers. The output of this step looks like this:
In step 2, you restart both Hyper-V hosts (HV1 and HV2). Since you run this recipe from the HV2 machine, the second command in this step reboots the HV2 system you are working on immediately (there is no prompt to ask you if you are sure or to save any work). If you test this recipe, make sure you have any files saved before you reboot.
In step 3, you configure HV1 to accept inbound replication from any Hyper-V system. If you have not configured the host firewalls (or turned them off) you may see errors trying to invoke replication.
You may also wish to configure HV2 to accept replication only from a specific server, such as HV1. To do this, you would have to set up the replication server to not accept replication from any server. Then, you use the Hyper-V cmdlet New-VMReplicationAuthorizationEntry to specify that HV2 can only receive replicas from the HV1 server. To set this up, you would do the following:
$RHT = @{
AllowedPrimaryServer = 'HV1'
ReplicaStorageLocation = 'C:Replica'
ComputerName = 'HV2'
}
Set-VMReplicationAuthorizationEntry @RHTIn step 12, you view the status of VMs on both HV1 and HV2. As you can see, the PSDirect VM is up and running (on HV2) with a replica VM on HV1, which is turned off.
In step 11, you view the details of the test version of the PSDirect VM running. If you were to open up a VMConnect window on this test VM, you see that both the hostname and the IP address are not the same as the VM running on.
After step 17, if you looked inside PSDirect, running this time on HV1, you would find the same issue. The impact is that after a real-life failover, you may need to reset the hostname and reset the IP configuration details. If you are using Hyper-V replica in production, it would be a great idea to develop a script to fix these two issues in an automated fashion.
In step 18, you see that the PSDirect VM is running on HV1 and stopped on HV2. However, if you look inside the PSDirect VM running on HV1, you see it has a hostname that is not PSDirect and has no networking setup. If you were to fail over and wanted to run the failed-over VM, you would need to deal with these two issues, which typically involves re-booting the PSDirect VM and possibly running a script to ensure the hostname and the IP configuration details are correct for your environment.