Virtual Architect

Is Live Migration a Necessity?

It's hyped as a must-have for data centers, but you can get similar fault tolerance from some Microsoft products, including Exchange.

• By Danielle Ruest and Nelson Ruest
• 03/01/2009

Live migration -- the ability to move a virtual machine (VM) from one host server to another while it's running -- has been touted high and low as a critical hypervisor feature for supporting a dynamic data center. It makes sense: To perform maintenance on a host server, you need to be able to move all of its VMs onto other host servers with minimum disruption to end users. Even more importantly, if your virtual workloads peak and need more resources, your virtual infrastructure should be able to automatically locate a host server with adequate resources and move the VMs to this host. And the entire process should be completely transparent to your end users.

Exchange Server Caveats
But hold on: Does everyone need live migration? Well, according to the Microsoft Exchange team, the answer is a resounding "no." On Sept. 16, 2008, the Microsoft Exchange team published its support policy for running Exchange in hardware virtualization environments, and confirmed that Exchange is supported in virtual environments running on Hyper-V and other hypervisors that have gone through the Server Virtualization Validation Program (including both VMware's ESX and Citrix's XenServer). But there are caveats -- major caveats. They include:

• The VM must be running Exchange Server 2007 with Service Pack 1 (SP1) on Windows 2008.
• The VM can't be running the Unified Messaging (UM) role. The Exchange team prefers that you run UM on a physical machine.
• The VM must be using either a fixed-size virtual disk or pass-through storage, which is linked to physical storage the way a physical installation would be.
• The VM must be running Exchange Server only.

Each of these requirements can be easily met, but here is the meat of the support policy:

• If you want to enable high availability for your Exchange VM, you must implement Cluster Continuous Replication (CCR) or the Single Copy Cluster (SCC) between two VMs. You must also rely on Exchange's own clustering capabilities to provide fault tolerance. In fact, you might opt for CCR because it relies on direct-attached storage and uses its own replication engine; that may make it the simplest to implement. The Exchange team doesn't support host-server clustering.
• The Exchange team doesn't support Live Migration features at the host server level.

So, if you want to virtualize Exchange in a supported configuration, you don't need any form of live migration. In fact, you only need to implement standalone host servers, something you can do with the free Hyper-V server, ESXi or XenServer Express, all of which do not support either clustering or live migration on their own.

You're not really losing anything, because Exchange provides its own fault-tolerance and live-migration features through the clustering service. Just make sure your two Exchange VMs are not on the same host; when you need to move the Exchange service from one host to another, you can cause a failover from one VM to the other. It's simple and straightforward.

Remember that you build machines in VMs just the same way you build them on physical systems-if you cluster Exchange in a physical configuration, then cluster it in VMs. If you place each clustered VM on a different host, then you have both live migration and fault tolerance.

Eye on Support Policies
Microsoft product teams are working hard to publish support policies for virtualizing the products and services in the server stack. And because many are virtualizing Windows more than other workloads, we'll be following these support policies closely. Watch this column for more information on this topic.