Support for Virtualising Exchange Server 2010 SP1 has changed..?
The support stance for virtualising Exchange Server 2010 SP1 has changed significantly over the last few days and seems pretty unambiguous. However you need to be a bit careful about what actually is and isn’t supported. The statement from Kevin Allinson on the Exchange Team blog yesterday reads:
“Combining Exchange 2010 high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers, is now supported.”
But I don’t believe it’s quite as straightforward as that statement makes it sound.
To quote the ‘Best Practices for Virtualizing Exchange Server 2010 with Windows Server® 2008 R2 Hyper V™’ whitepaper:
“Exchange server virtual machines, including Exchange Mailbox virtual machines that are part of a Database Availability Group (DAG), can be combined with host-based failover clustering and migration technology as long as the virtual machines are configured such that they will not save and restore state on disk when moved or taken offline. All failover activity must result in a cold start when the virtual machine is activated on the target node. All planned migration must either result in shut down and a cold start or an online migration that utilizes a technology such as Hyper-V live migration.”
In a nutshell it means that something like Hyper-V ‘Live Migration’ is supported but something like Hyper-V ‘Quick Migration’ is not, since ‘Quick Migration’ saves, moves and restores the virtual machine; ‘Live Migration’ does not. To quote the ‘Windows Server 2008 R2 Hyper-V™ Live Migration’ whitepaper:
“Live migration and Quick Migration both move running VMs from one Hyper-V™ physical computer to another, the primary difference is that Quick Migration saves, moves and restores a VM which results in some downtime. The live migration process uses a different mechanism for moving the running VM to the new physical computer. This process will be explained in greater detail in the Live Migration Architecture section of this document. Below is a summary of the live migration process:
1. All VM memory pages are transferred from the source Hyper-V™ physical host to the destination Hyper-V™ physical host. While this is occurring, any VM modifications to its memory pages are tracked.
2. ™Pages that were modified while step 1 was occurring are transferred to the destination physical computer.
3. The storage handle for the VM’s VHD files are moved to the destination physical computer.
4. The destination VM is brought online on the destination Hyper-V™ server.
Live migration produces significantly less downtime for the VM being migrated.”
Since VMware VMotion technology is broadly similar in terms of application as ‘Hyper-V Live Migration’ that too would be supported.
This change in the support stance is significant for two reasons in my opinion. Firstly it will mean more Exchange deployments on Hyper-V where previously the choice appeared to be virtualise Exchange Server on a VMWare solution or don’t virtualise at all; and secondly it means a lot more choice for deploying Exchange 2010, which I think is a good thing.
What it doesn’t mean is that virtualising Exchange will always make sense. The most successful Exchange Server 2010 solutions in the enterprise that I have been involved in have not as yet featured Exchange running on hardware virtualisation software since it has not made sense to do so.. However the case for virtualising Exchange Server specifically is increasingly compelling.
As always check vendor participation in the Windows Server Virtualization Validation Program and continue to keep up with the ‘ Exchange 2010 System Requirements ’ specific to ‘Hardware Virtualization’.