Freigeben über

Keeping VM Configurations in Sync with Hyper-V Replica

  • Artikel

Yesterday I posted about my new home setup, which makes heavy use of Hyper-V Replica.

When you first setup Hyper-V Replica for a virtual machine – we copy the virtual machine configuration and storage from the primary server to the replica server. From that point on we replicate any new data that is written to the virtual machine storage – but we do not replicate any new changes to the virtual machine configuration.

Why?

Well – there are two reasons for this:

  1. We have many deployments where the Hyper-V administrator on the primary and replica servers are different people (e.g. a small business replicating to a local service provider). In this case the administrator on the replica server is not going to want the administrator on the primary server to be able to make arbitrary configuration changes.
  2. There are a number of configuration changes where you want things to be different. E.g. you may want the virtual machine on the replica server to be connected to a different network or to have a different amount of memory, etc…

While this all makes sense, it has tripped me up a number of times. The scenario I have experienced is this:

  1. Enable Hyper-V Replica on a virtual machine
    … months pass …
  2. Make a configuration change to the virtual machine, forgetting that it is configured for replica
    … months pass…
  3. Perform a planned failover of the virtual machine for some reason, and wonder why all the settings are wrong!

After having this happen to me a couple of times – I have taken to using PowerShell to perform quick sanity checks on my virtual machine configurations. This is actually quite easy to do – as PowerShell allows you to target multiple physical computers with one command.

Some checks that I have done include:

Checking memory configurations:

This command will get all the details of the memory configuration from two servers:

get-vm -computername Hyper-V-1, Hyper-V-2 | select name, DynamicMemoryEnabled, MemoryStartup, MemoryMinimum, MemoryMaximum | Sort-Object name | ft

Which looks like this when it is run:

clip_image001

Checking startup delay:

This command shows you all the startup information:

get-vm -computername Hyper-V-1, Hyper-V-2 | select name,automaticstartaction, automaticstartdelay | Sort-Object automaticstartdelay, name

clip_image002

Checking MAC address configuration:

I use DHCP with MAC address reservations in my house, so it is critical that virtual machines not change their MAC address. This command shows you what MAC addresses are being used, and whether dynamic mac address generation is enabled or not:

get-vm -computername Hyper-V-1, Hyper-V-2 | Get-VMNetworkAdapter | select VMName, macaddress, DynamicMacAddressEnabled | sort-object VMName, macaddress

clip_image003

Cheers,
Ben

Comments

  • Anonymous
    November 05, 2013
    Great article Ben. I wasn't aware of that replication limitation. Is there a way to replicate the VM configuration changes?

  • Anonymous
    November 06, 2013
    Is there a way to replicate the VM configuration changes?

  • Anonymous
    November 13, 2014
    This "behavior by design" is just an excuse for not actually having an option to enable/disable configuration file sync on top of the VHDs. Let me guess, "please upgrade to Windows Server 10"?

  • Anonymous
    February 03, 2015
    Why we don't have an option to replicate vm's configuration or not? I don't understand why it is "by design".

  • Anonymous
    February 04, 2015
    Today, Hyper-V Replica only syncronizes VM's data (Vhd), when we change primary VM configuration (vcpu, memory, create a new vhd, etc), these changes is not replicated to replica VM. We are a cloudhoster and we check daily if our customers made changes on their primary vm's, when this occurs, we need destroy vm's replication and create again. This is not good because is a big effort to get all configurations syncronized. Today we have 800 vms, our customers are adopting replication and I think we will not have conditions to manage replication in this way. My doubt is: Do you have intention to launch an update to permit, also, synchronize vm's configuration changes?