AMD Best Practices Series.  A Contributed Series by AMD. 

Migrating with Microsoft is written by Tim Mueting, Product Marketing Manager at AMD 

Migrate (verb) - to shift, as from one system, mode of operation, or enterprise to another. 

With the release of Microsoft Hyper-V^TM R2 and Windows Server 2008 Hyper-V^TM R2, Microsoft included the long-awaited virtualization feature, Live Migration.  According to many industry experts, this was the most important virtualization feature introduced with the release.  I tend to agree for a number of reasons.  First, for the uninitiated, Hyper-V Live Migration enables the migration of a running virtual machine from one Hyper-V physical host to another without any disruption of service or perceived downtime.

As IT professionals are increasingly adopting virtualization for their datacenter workloads, live migration is one of the features being used to help create a dynamic and flexible IT environment that can respond quickly to emerging business needs.  Live migration provides the core technology to implement dynamic load balancing and high availability for virtualized workloads, and helps to eliminate downtime during scheduled maintenance tasks.  The flexibility that live migration provides can also play a critical role in the growth and success of a variety of cloud computing infrastructures as well.  In fact, I've written a number of times on the importance and various uses of "live migration" with regards to virtualization. 

Prior to Live Migration, Microsoft had a feature called Quick Migration.  The primary difference between the two is that with Quick Migration some downtime is incurred as the system saves, moves and then restores the VM on the new physical server.   Live Migration, on the other hand, pre-copies the memory of the migrating VM to the target physical server, which minimizes the time it takes to transfer the VM.  Both options are still supported, but with Live Migration there is no impact on availability to the users; they aren't even aware the migration is taking place. 

You might be asking, "What about processor requirements?"   I've talked previously about the requirements for VMware's Vmotion feature with regards to different processor revisions and processor architectures and as you might imagine, there are similar restraints with Hyper-V's Live Migration feature. 

A few requirements

First, Microsoft Live Migration requires the physical hosts to be configured with Microsoft Failover Clustering Services as a Failover Cluster.  The cluster should be configured with a dedicated network for live migration traffic and each physical host must use shared storage.

Also - and this won't surprise many of you - both of the physical hosts must use processor(s) from the same manufacturer.  For situations where the cluster isn't standardized with identical hardware and processor types, Microsoft implemented a feature called Processor Compatibility Mode.   For example, Processor Compatibility Mode enables you to migrate a VM from a Quad-Core AMD Opteron^TM processor-based server to our newest 12 Core AMD Opteron 6100 Series processor-based server, or between a Dual-Core AMD Opteron Rev F processor-based server and a Quad-Core AMD Opteron processor-based server.

Processor Compatibility Mode identifies a baseline feature set for the cluster by hiding the set of features that differ among all processors within the cluster.  The Hyper-V hypervisor uses a feature of AMD Extended migration called CPUID to determine the VM's processor type (revision) and features and then clears the returned bits corresponding to the hidden features.  It is also important to note that Processor Compatibility Mode can only be enabled or disabled while the VM is down. For a complete look that Microsoft Hyper-V Live Migration I suggest downloading the white paper Window Server® 2008 R2 Hyper-V^TM Live Migration.

Are you using Hyper-V Live Migration today?  How has the decreased downtime affected your workflow?  Does Hyper-V Live Migration impact your cloud computing infrastructure plans?  I'd love to hear about your experiences.

About the Author

Tim Mueting is a Product Marketing Manager at AMD. His postings are his own opinions and may not represent AMD's positions, strategies or opinions. Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such linked sites and no endorsement is implied.

The AMD Virtualization Blog can be found here.