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.

Please follow and like us:

6 Comments on Exchange Support Policy for Virtualization

  1. Ivailo Tzenkov // May 25, 2010 at 2:12 PM // Reply

    Great article! I’ve wondered why they don’t support it, too. We have two physical offices and we do need DAG; furthermore, we have virtualized everything else and the option to have Live Migration is a must for us – so I am thinking of just bypassing this requirement…

    • Aidan Finn // May 25, 2010 at 7:04 PM // Reply

      This is exactly the sort of scenario I was thinking of. I bet that most people who implement DAG & virtualization will either not know this support statement or will ignore it, taking a risk.

  2. We virtualize all we can, and will probably also choose to ignore that and use DAG on virtualized. You say that you have concluded that dynamic VHD is bad in production, why is that? MS says the speed with it is so good it should be no problem

    • Aidan Finn // May 27, 2010 at 10:23 AM // Reply

      We are noticing speed issues. On one VM, we made the switch from dynamic to fixed. The application on it suddenly got a 20% boost in performance. Fragmentation is an issue with dynamic VHD…. lots of dynamic VHD’s, all on a single LUN, all trying to grow a little bit at a time. Eeek! Do a bit of research and you’ll find none of the big player server apps in Microsoft will recommend dynamic VHD. They all say you should use fixed VHD or passthrough.

  3. Thanks for you reply. Great to get some inputs from other using it

  4. Evan Erwee // July 14, 2010 at 7:18 PM // Reply

    I tested it and it does corrupt data in Hyper-V using StarWind iSCSI target.

Leave a comment

Your email address will not be published.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.