The idea of virtual machine migrations between physical hosts is a key selling factor for virtualization. Patching,
hardware outages and configuration updates are no longer at the mercy of outage windows and failing hard drives or fans. This ups the nines on reliability without having to rely on expensive specialized hardware.
But there is one caveat -- shared storage. And not just any shared storage, but fast shared storage, which is often a high-end iSCSI NAS or Fibre Channel-connected SAN solution. "Fast" means expensive, and often unnecessary, in certain cases. Sure, your best performance will come from a connected SAN, but a small business or a remote office will see this as overkill.
The newest editions of popular hypervisors are building in a "shared-nothing" concept to disconnect storage and the clustered requirement. This means local storage and migrating a virtual machine between two hosts with internal disks are now available.
VMware integrated shared nothing into vMotion when they recently released ESXi 5.1, but VMware requires a specific level of license to use the feature. Hyper-V, on the other hand, has made this feature available to any server running Hyper-V 3.0.
Using shared storage will still result in the fastest and most efficient live migration. You can't compete with moving just the contents of memory instead of a multigigabyte virtual hard disk file over a network connection. The big win with shared nothing is flexibility. You don't have to allocate unnecessary SAN storage or buy an expensive solution just to get higher availability for your small business. You have the option to get live migration in Hyper-V without the headache of shared disk. Just know the tradeoffs with speed and the configuration requirements before you start.
How to share with shared nothing
The original requirement was that all hypervisor hosts required access to the same storage logical unit number. When the original host released the virtual machine, the other host could simply take over the virtual hard disk (VHD) file once the contents of the virtual machine's memory were transferred via live migration. This also meant your hosts needed to be configured in a cluster so that they were aware of each other's resources.
If you wanted to transfer the machine without shared storage, or that host was not part of the cluster, you would have to shut down the machine and migrate the server. Before, this was essentially a file copy process with enough downtime to be noticeable. Now, Hyper-V pushes the entire disk across your network while the VM is online without any need for cluster membership or shared storage of any type.
Hyper-V achieves this by using some intelligent storage tricks. While a VHD is being copied over the network, any reads or writes requested of the disk are coming from the original source disk. Any changes are logged, and once the original copy is complete, the updated writes are applied to the source and destination VHD files. Once this sync is complete, Hyper-V will bring the copied VM online on the destination host and delete the source VHD.
Implementing shared-nothing live migrations
The big win with shared nothing is flexibility.
The list of requirements for a shared-nothing live migration is quite a bit shorter than that of using shared volumes. In fact, all you need are two or more servers running Hyper-V 2012 (either the dedicated server or the role running in Windows Server 2012) within the same processor family (Intel or AMD), joined on the same Active Directory domain. The network is critical in any virtual environment, but with shared nothing you'll want to get very fast network connections. Provide nothing less than 1 Gb links that are preferably set up on a private network connection exclusively for live migrations.
Your storage location for the virtual machines can be locally attached NT file system (NTFS) disk, a SAN or a standard SMB 3.0 file share. You cannot use pass-through disks. You must use virtual hard disks for storage, which is requirement for any live migration scenario. When using a file share, it must be visible to both the source and destination hosts.
Why would you want to use shared-nothing live migration if you have a SAN when it can also be used when doing live migration in a cluster? Remember that these machines are not clustered, so even though it may be on a dedicated storage network, they are not sharing that storage. This can be useful when moving virtual machines to new storage or moving them to a host a new cluster for load distribution.
Authenticating live migrations
Once you have the requirements met, you need to enable live migrations in the Hyper-V settings for the host by checking "Enable incoming and outgoing live migrations." From there, set your options for authentication, number of simultaneous live migrations allowed (which is another change from the previous limit of one) and what IP addresses are allowed for incoming live migrations.
The issue of credentials is an important one. Any administrator who plans on doing remote management of these servers should pick Kerberos as the authentication option and get the servers matched for authentication type and delegation of computer accounts.
This will require you to do some configuration work to set up delegation. Server 1 will need to delegate Server 2 for the Microsoft Virtual System Migration Service and vice versa on the other host. Include the Common Internet File System (CIFS) service as well if you plan on migrating from a file share. You can access the Delegation tab from the Active Directory Users and Computers console and open the computer object properties.
Moving the virtual machine
Once you have your authentication configured and your live migration networking setup -- either to pass on any NIC, or preferably, dedicated to a single private network space for security and speed -- you'll have the option to move the virtual machine.
The Move wizard walks you through picking the destination Hyper-V server and where to move the various items. You have the option to move snapshots, the VHD and the configuration to different locations, or you can put them in one spot. Once you've picked a destination folder, the move begins. The speed of the move depends on how big the VM is in disk and memory size, as well as the speed of your network. Expect minutes for your migration, not seconds.
ABOUT THE AUTHOR
Eric Beehler has been working in the IT industry since the mid-1990s and has been playing with computer technology well before that. His experience includes over nine years' experience with Hewlett-Packard's Managed Services division, working with Fortune 500 companies to deliver network and server solutions; and most recently, IT experience in the insurance industry working on highly-available solutions and disaster recovery. He currently provides consulting and training through his co-ownership in Consortio Services, LLC.