Hyper-V live migrations tips…

Here’s a list of various things which I encountered when doing live migrations of VMs between HyperV hosts. Maybe they’re helpful to other people as well.

• If the VM uses DHCP then first configure it’s MAC address static so the  address stays the same (under network). Please note: this can’t be configured when the server is running and the same goes for the next item.
• If the new host has different hardware enable the Compatibility Configuration under the processor options.
• Enable the live migration (I didn’t use Kerberos) on both machines and temporarily disabled the firewall on the receiving machine
• If the new host has different hardware enable the Compatibility Configuration under the processor options.
• Launch a RDP session to the source machine and start the migration by selecting the server and chose move
• After the migration, disable the Compatibility Configuration if it was enabled for best performance
• Disable the live migration on both servers and re-enable the firewall

IMHO the kerberos authentication isn’t needed for the occasional migration in an isolated network segment.

 

I encountered two issues which took some time to figure out:

• If you use Data Protection Manager you’ll first have to remove the VM’s from DPM before you can select them on the new host (refresh doesn’t work!)
• Permissions error during migration? In my case the virtual machines group was missing from the snapshots folder on the destination server. Take a look at the original VM folder permissions and add it to the folder which needs this. This seems to be impossible from the GUI so start powershell and use these commands to add full control of this group to, for example, d:\hyperv

$sid=get-acl d:\hyperv

$sid.SetSecurityDescriptorSddlForm( ($sid.sddl + “(A;;FA;;;S-1-5-83-0)(A;OICIIO;0x101f01ff;;;S-1-5-83-0)”) )

set-acl d:\hyperv -AclObject $sid​

 

If you want a more secure, fine grained approach to set the folder permissions please take a look at this article.

 

• Migrating from an older HyperV hosts (2012R) to server 2019 can result in a VM that won’t start with the network adapter being present. This can be caused by a bug – a work around is to change the MAC address.

And a new attempt fix the Litterbot problem…

Alas, in the end the previous idea didn’t turn out to be the definite fix as the issue suddenly came back. So let’s try something different… maybe it’s the contacts between the base and the bonnet which is causing the yellow light to blink? I had already cleaned them several times but I noticed some wear on them and the contacts aren’t working that well anymore.

To test this I’ve soldered a wire on both the base and the bonnet connectors and coupled  them as shown in this picture:

So let the testing begin…  🙂

Please note that it’s possible that this mod can damage the machine because the contacts are used as some kind of mechanism to detect overload. For example, maybe the globe pushes the bonnet up by design when it’s not able to rotate properly. Thus breaking the contact on purpose!