There has been a lot of drama recently between Microsoft and VMware with respect to virtualizing Exchange 2010. The background and details are summarized well in this article (in which I’m quoted). I think this situation brings up some important points about virtualizing critical Tier 1 applications – vendor support is very important, and disregarding vendor requirements for support can lead to problems when you need support the most.
There are a number of seemingly strange support requirements from Microsoft and VMware which often leads people to get confused on what is supported or how to configure their environments. A few of them are listed below:
1) You cannot use VMware HA in conjunction with virtualized Exchange 2010 mailbox servers that participate in a Database Availability Group. This is the issue referenced in the link above.
2) You cannot virtualize Microsoft Failover Clusters (of any kind) on iSCSI storage as of VMware vSphere 4.1.
3) You cannot use NAS storage for virtualized Exchange servers, even if it is presented to the guest as block storage.
These are just a few examples of some of the support policies of both VMware and Microsoft. Some people might throw up their hands in disagreement with these policies and end up disregarding them. I think, for the most part, folks should try to stay within the support guidelines of the application being virtualized. That is especially true if we’re talking about a Tier 1 application like Exchange or SQL.
Many people are quick to criticize Microsoft for their support policies and blame them for this situation. While Microsoft doesn’t have the best reputation for supporting competing vendors, I have to give them some credit here for their policies on virtualization in general. They’ve created an entire program called the Server Virtualization Validation Program (SVVP) to validate their software running on competing hypervisors. They have also made it easy to virtualize Windows with virtualizaiton friendly Windows Datacenter licensing. Microsoft isn’t perfect here but they are also not anti-virtualization either.
Some of the features that aren’t supported can be disabled quickly when vendor support is needed, but is that really a good idea? That might work for non-critical support calls, but in a major disaster scenario the administrator may not remember to disable those options and could encounter supportability problems. Or another administrator who isn’t familiar with the support policies may end up being the one who has to open the support case and wouldn’t know to disable these features. Not a good situation to be in.
I am not saying that I agree with or comply with every single one of these support policies. Many of them are silly or make no sense at all and have no technical reason behind them. My long winded point here is that you shouldn’t take a chance with vendor support on your most important applications. Email systems, SQL servers, accounting systems, etc, are all usually too important to a business to risk not getting support when they need it the most.
Designs can change as support policies change, but until they do I’m sticking with what keeps me supported.
Some references for support policies:
VMware support for Windows Clusters (PDF)