Improved Live Migration

Live Migration was introduced in Windows Server 2008 R2 to provide a high-availability
solution for VMs running on Hyper-V hosts. Live Migration uses the Failover Clustering feature to allow running VMs to be moved between cluster nodes without perceived downtime or loss of network connection. Live Migration provides the benefit of increased agility by allowing you to move running VMs to the best host for improving performance, achieving better scaling, or ensuring optimal workload consolidation. Live Migration also helps increase productivity and reduce cost by allowing you to service your host machines without interruption or downtime for your virtualized workloads.
Live Migration in Windows Server 2008 R2 required storing VMs on an Internet Small Computer Systems Interface (iSCSI) or Fibre-Channel SAN. In addition, Live Migration in Windows Server 2008 R2 supported performing only a single Live Migration at a time— multiple simultaneous Live Migrations were not supported.
Now Live Migration in Windows Server 2012 has been improved in several significant ways.
First, Live Migrations can be performed much more quickly. In fact, you can even saturate a
10 GB network connection when performing a Live Migration between Windows Server 2012
Hyper-V hosts, something you couldn’t do before with Windows Server 2008 R2 Hyper-V
hosts.

A second improvement to Live Migration in Windows Server 2012 is that now you can perform multiple Live Migrations simultaneously within the same failover cluster. This
means, for example, that if you needed to take down a particular cluster node for immediate servicing, you can migrate all running VMs from that node to a different node quickly and simultaneously in a single operation using either the GUI or a Windows PowerShell command. This can greatly simplify the task of performing maintenance on Hyper-V hosts within your environment.
A third improvement is that Live Migration is now possible even if you don’t have a failover clustering infrastructure deployed. In the previous version of Windows Server 2008 R2, Live Migration required installing the Failover Clustering feature, and you also needed to ensure that Cluster Shared Volume (CSV) storage was enabled to ensure the logical unit number (LUN) on which your VM is stored could be accessed by any cluster node at any given time. With Windows Server 2012, however, you have two additional options for Live Migration that can be performed outside a failover clustering environment:

■ You can store your VMs on a shared folder on your network, which lets you

live-migrate between non-clustered Hyper-V hosts while leaving the VM’s files on
the share.

■ You also can live-migrate a VM directly from one stand-alone Hyper-V host to another without using any shared storage at all.

Let’s look at these two Live Migration options in a bit more detail.

Live Migration using a shared folder

With Hyper-V in Windows Server 2012 you can now store all of a VM’s files on a shared folder on your network provided the shared folder is located on a file server running Windows Server 2012 (see Figure 2-6). The reason the shared folder must be located on

a file server running Windows Server 2012 is because this scenario is supported only through the new capabilities of version 3 of the server message block (SMB) protocol (SMB 3). For more information about SMB 3 and the new continuously available file server capabilities of Windows Server 2012, see the section titled “SMB 3,” later in this chapter.

SMB 3 file server

Live Migration

FIGURE 2-6 Live Migration using SMB 3 shared storage but no clustering.

Live Migration using SMB 3 shared storage does not in itself provide high availability unless the file share itself is also highly available. It does, however, also provide the benefit of enhanced VM mobility. And this added mobility can be achieved without the high costs associated SANs and their associated switching fabric. SANs also add extra management overhead in the form of provisioning and managing LUNs. But by simply deploying
a Windows Server 2012 file server, you can centralize storage of the VMs in your environment
without the added cost and management overhead associated with using a SAN.
Live Migration using SMB 3 shared storage does have a couple of requirements to get it to work, namely the permissions on the share must be configured appropriately, constrained delegation must be enabled in Active Directory directory service, and the path to the shared storage must be configured correctly in the VM’s settings. But once everything is set up properly, the procedure for performing Live Migration is essentially unchanged from before.

Experiencing SMB share hosting

eing an infrastructure consultant for the better part of my IT career has included some very deep and thought-provoking discussions about the best

ways to accomplish certain goals. Whether the dialogue was comprised of topics such as virtualization, storage, or applications, the common theme throughout was clearly protection of one’s digital assets and data. Everyone wanted to design a cost-effective (operative term) disaster recovery solution for their workloads without affecting performance or user impact; however, we all know that you get what you pay for when disaster recovery solutions are concerned.

It was recently told to me that the number two reason for a company implementing a virtualization strategy is disaster recovery. That makes sense to me; however, most of the underlying infrastructure required for a physical server disaster recovery environment is still required in the virtualized world. We still needed the replication of our data through underlying storage. We still needed the like “cold spare” hardware to pick up where our primary servers left off. Don’t get me wrong—these solutions are fantastic, but in the end, are quite costly. There needed to be a way

to ensure that the smaller IT budgets in the world did not fall to the bottom of the

“you get what you pay for in disaster recovery” bucket.

Enter Windows Server 2012. In my opinion, this is truly the first “cloud-ready” piece of software that I have seen capture the entire portfolio of cloud readiness features. Shifting the focus to the mobility of workloads (which is the basis for improving upon current disaster recovery functionality) was clearly a theme when designing this software. The ability to never have to turn your VM off, regardless of scenario,

is the holy grail of disaster recovery.

So of course, being an engineer, I wanted to play with this stuff. After installing a couple of Hyper-V and file servers, I decided to test an SMB share hosting my VM files. As generally non-complex as that sounds, it was quite cool to see my associated virtual hard disk (VHD) be linked to a network path.

Just a tip: For POC setup, make sure you have solid name resolution going on

(which often gets overlooked in labs), or alternatively, use IP addresses.

I decided to see what I could do with this share, and without knowing, stumbled upon an improvement to Live Migration. In Windows Server 2012, you can seamlessly migrate a VM hosted on an SMB file share (This needs to be SMB 3— currently Windows Server 2012 only) to any other host in the same domain (given share permissions). I chose to move my machine to another host of mine, and before I was able to Alt-Tab to the documentation and back, my VM had already moved. What I forgot about at the time of migration was that I never did

any prerequisite storage configuration on any of the host machines, which made the whole experience much more exciting. It just worked. I couldn’t wait to couple this with the other optimization technologies built in to the operating system

(de-duplication and compression) for some real gains.

Then, my engineering mind went to the next obviously logical step: “Okay, how can I break this thing?” The demos I had seen on this had shown Live Migration with workloads such as pings and file copies. That just didn’t do it for me . . . I wanted

my VM to host streaming video. With my setup in place, I streamed not one, but

two video files to different clients on my network and monitored them. One stream was a simple AVI file hosted on a file share. The other was a high-definition video

file hosted by a server-side transcoder that was streaming to my laptop. I also had

a ping going just for kicks. The CPU had settled around 30 percent on the VM once both videos were going, so I was interested to see what the results would be. Once Live Migration kicked in, I was watching for any blip or interruption to the video files, with no result. The best interruption, almost amusingly, was a dropped ping in my command prompt. Being overly satisfied with my little demo environment,

I proceeded to watch the rest of my movie.

To sum up, mobility is the key. There is a huge array of other features that Windows Server 2012 comes to the table with. As you’re reading the rest of this book, keep in mind the high-level view of cloud readiness and how all of the features in Windows Server 2012 play towards this common goal.

Ted Archer

Consultant, Virtualization and Core Infrastructure