Exchange Support Policy for Virtualization

I’ve previously blogged about this but I’ve been asked about it recently so I’m posting again.  I’ve also been watching lots of webcasts and reading web pages on the subject.

You an read the original text on the Microsoft TechNet site.

The first and most important thing to know is that Microsoft does not support the usage of DAG (database availability group) members on clustered virtualization solutions (Hyper-V, Xen, VMware, etc).  Their phrasing is that Exchange clustering solutions cannot be used on virtualization solutions.  No quick migration, no live migration, no vMotion, nothing.  This means that CCR and SCC are also not supported.

That’s it.  Simple as.  No negotiations.

I find this a little odd.  SQL supports guest failover clustering, host clustering, database mirroring in clustered virtual machines.  Other MS applications that use the ESE database have no issues with highly available virtualization.

What this means is that if you want to run Exchange DAG members as a virtual machine(s) then you need to run them on standalone hosts.  There’s no point in having one host; you’ll need two.  If you’re doing that then you’ll have at least two CAS, hub transport, CAS/Hubs, Edge, etc.  You can probably place one of each on your standalone hosts.

Why doesn’t Exchange support DAG on highly available virtualization?  I cannot think of a technical reason.  The Exchange product team has not shared one with us.  I’ve heard whispers of data corruption but I suspect that is pure speculation.  If you use Live Migration then you know that there is zero network traffic loss.  The “downtime” is 2 milliseconds; less than a TCP/IP timeout for single packet.  So it cannot be the fact that a VM is moved using Live Migration that is causing an “issue”.

[speculation] If I had to guess then here it is: The Exchange product group didn’t test it.  Usually, if an MS team doesn’t test something then they won’t support it.  Sometimes there are technical failings that cause the lack of support.  But when no reasons are given then that means they just didn’t have time, didn’t have the equipment or just didn’t see the point. I’m going out on a limb here: Exchange has been known to emphasise deadlines before product in the past (Exchange 2007 SP1 finished the product) and I would wonder if they just didn’t figure if the testing time was worth it.  They just couldn’t test Hyper-V; they’d have to cover all of the hardware virtualization solutions in SVVP.

Some people don’t _get_ virtualization so they don’t get the need for people to virtualize a Exchange VM’s with fault tolerance.  I’ve heard the argument: “why would you want to put highly available Exchange on a Hyper-V cluster?”.  Duh!  For all the usual virtualization reasons.  Any why on a cluster?  Because you don’t want to purchase host hardware just for Exchange.  Not everyone is one of the Fortune 1000’s and some of the reasons we virtualize is to get fewer physical hosts and lower ownership/operating costs.  A well designed, modern host can run a lot of high utilization VM’s. [/speculation]

Other stuff you should know about when it comes to Exchange (2007 SP1 and later) on hardware virtualization:

• Normally you get 8:1 vCPU to logical processor ratio in Hyper-V.  Exchange supports a 2:1 ratio.  Understandable if they believe Exchange will be a CPU eater.
• Dynamic VHD is not supported.  You have to use fixed VHD or passthrough disk.  I’m finding that this is a common one.  I’ve come to the conclusion that dynamic VHD is bad in production.  SQL has the same requirements. You can also use iSCSI storage that is initiated by the guest VM.
• The UM role cannot be virtualized.  This makes sense.
• Snapshots of a VM are not supported – this requirement is on every application I’ve checked out so far.
• Exchange 2003 is not supported on anything but Virtual Server 2005 R2 SP1.

I understand these requirements.  But I really do not get the clustering one. There isn’t an official technical reason that I know of.  It would be good if the Exchange product group got around to addressing this publicly before they got all wrapped up in Exchange 2010 SP1.