It's alive! Shared-nothing migration puts the spark into Hyper-V

Freedom of movement

Shared-nothing live migration may be the most exciting feature to emerge from Microsoft's Hyper-V 3 virtualisation push.

Shared-nothing migration is the ability to move a virtual machine from one virtual host to the another where those hosts lack mutual access to centralised storage. The "live" part means the virtual machine does not have to be turned off.

When it comes to storage, the enterprise lives and breathes high availability (HA).

High and mighty

HA requires some form of shared storage, maybe a storage area network (SAN), a network-attached storage (NAS) device, or a group of hosts lashed into a clustered storage solution such as Microsoft Scale Out File Server, VMware's vSphere Storage Appliance, Nutanix and so on.

By definition, shared-nothing live migration lacks the shared storage component. If you want to move a virtual machine using it HA is not really an option. But shared-nothing live migration is still relevant to the enterprise.

If you are migrating virtual machines between hosts in different clusters you should disable HA first, as you do when you move a virtual machine from a cluster to a non-clustered host.

No downtime is required to disable HA. Technically you do not have to turn off HA, but the details of the migration process – namely that it is doing more than synchronising RAM, it is sending a potentially huge virtual hard disk (VHD) file, and trying to synchronise changes on that as well as the RAM – mean that it is relatively easy for glitches to tank the virtual machine.

Treat the thing as a live-wire virtual machine that needs handling with kid gloves

I think it is better to turn HA off and treat the thing psychologically as a live-wire virtual machine that needs handling with kid gloves.

It is trivial to disable HA if you use Windows PowerShell to do your migrations. Running a shared-nothing live migration of the virtual machine from one cluster to another and then re-enabling is also trivial.

If you use the GUI it is a few extra mouse clicks and a matter of a few seconds during which that virtual machine is theoretically vulnerable to a single host failure.

Shared-nothing live migration is an important concept as we start to move towards the software-defined datacentre. Flinging virtual machines between clusters will become increasingly commonplace, and eventually it will be automated. This feature delivers the foundation of that functionality.

What small businesses want

Shared-nothing live migration is useful for enterprises, and a critical enabler for small and medium-sized enterprises (SMEs).

Few SMEs have the IT budget to buy a proper SAN. Shared storage can be done on a NAS, but that is its own can of worms. NASes tend to have fewer IOPS and are production ready only at the expensive high end.

You can of course run your Hyper-V virtual machines off of a central SMB store, typically a Windows Server. This can be as fast as you choose to make it – the upcoming Server 2012 R2 even includes flash caching.

This would remove the need for shared-nothing live migration but is also one more device that many SMEs simply don't want to be bothered with.

SMEs may well not need HA; where they do, it is rarely necessary for all virtual machines. Given budget pressures, SMEs tend to use shared storage only for those virtual machines that require it, using direct-attached storage and more traditional backups for everything else.

I have built – and still operate – setups with 30 hosts and 250 virtual machines running like this. Without shared-nothing live migration you have to turn the virtual machine off, migrate it from one host to another and then turn it on.

This can take hours, depending on the size of the virtual machine. That kind of downtime is a show stopper for most businesses and can place an operational burden on the IT department, which has to schedule an outage just to move a virtual machine. That usually means long nights at the weekend.

Shared-nothing live migration solves the problem at a stroke. Built into Microsoft's free Hyper-V server, it represents a significant cost saving for SMEs.

SMEs don't usually get budget to buy licences for virtualisation software for test labs. They could well be running a lot of open-source software. So an SME could build a small datacentre out of Hyper-V server hosts without paying Microsoft a dime and merrily fling virtual machines from server to server without coughing up for a SAN.  

Reality bites

In theory, shared-nothing live migration is just plain awesome, applicable to most businesses using virtualisation. That is to say most businesses.

The reality differs somewhat. This is a true 21st-century v1.0 technology. It works and it works well, but it is dependent on many different technologies for which a joined-up and easy-to-use interface has not yet been made by anyone.

The first thing to be sure of – as with all virtual machine live migrations, shared storage or no – is that you have processor compatibility between your hosts.

If they are incompatible, the Hyper-V solution is fairly straightforward: go into the virtual machine properties and check "migrate to a physical computer with a different processor version". This can be done only when the virtual machine is powered off.

When the virtual machine moves from server A to server B, it will look for a virtual switch with the same name. If your network adapter on the virtual machine resident on server A is set to look for a virtual switch called "LAN1" and server B has no "LAN1" virtual switch, the migration will not complete.

It is good if checks for this are run before the migration is tried. If an issue is found, offer remediation from within the migration wizard, rather than forcing the administrator to back out, make the change and relaunch the wizard. This is a minor nitpick, but I'm a stickler for administrator-friendliness.

Another stumbling block is authentication. This is one of those areas where the argument about the clue of management tools starts to rear its head. In Microsoft's ecosystem there are two ways to enable authentication between servers so that the shared-nothing live migration can take place: Kerberos and CredSSP.

If your domains are part of the same domain, set it to use Kerberos. If they are not, use CredSSP and a prayer.

I do not recommend CredSSP in a real-world production environment. The short version why is the same reason why we use centralised authentication systems such as Active Directory in the first place: the alternative is to keep identical users across multiple systems, keeping passwords in sync and so forth.

To get Kerberos to work, you need to configure constrained delegation on the hosts. in plain English this means "the servers involved in the shared-nothing live migration need to be able to manipulate services on each other and need to have the security rights to do so".

The process of enabling Kerberos constrained delegation via GUI is:

1. Enable "advanced view" in Active Directory Users and Computers.

2. Open properties of the host’s computer account and go to Delegation tab.

3. Add the computer accounts for all the other hosts this host might live migrate to.

4. Add the CIFS and Microsoft Virtual Machine Migration Service services.

5. Wait for active directory replication to complete.

6. Reboot the host you just edited so that it can pick up and apply its new settings.

This has to be done for every host that might be involved in shared-nothing live migrations. Party time with your mouse buttons and a long series of boxes.

The alternative is a bit of PowerShell:

  Get-ADComputer [host you want to configure]| Set-ADObject -Add @{"msDS-AllowedToDelegateTo"="Microsoft Virtual System Migration Service/[FQDN of host you are granting access]", "Microsoft Virtual System Migration Service/[hostname of host you are granting access]", "cifs/[FQDN of host you are granting access]", "cifs/[hostname of host you are granting access]"}

If you plan to attempt shared-nothing live migration using only Hyper-V server or the native management tools built in to Server 2012, it is a good plan to get hold of the right reading material.

Pity the little people

The alternative is to stump up the money for System Center Virtual Machine Manager, which deals with all this host-configuration drudgery for you.

Regardless of who is your preferred vendor – Microsoft or VMware – the functionality exists and it is only realistically usable if you get the management tools.

This pushes the feature out of the hobbyist and lower-end SME range. Personally I regret that, as this is the segment (those who can't afford shared storage) where it would do the most good.

The truth is that shared-nothing live migration is useful outside the SME space – useful enough to drive sales from businesses that have money to spend on licences. It won't be commoditised any time soon: you will pay in man-hours or you will pay for licences.

Either way, shared-nothing live migration is not just another tickbox item or a throwaway concept that can be ignored when reviewing your next upgrade.

It is one of the foundational technologies of the next generation datacentre. Once you have used it, there's no going back. ®