After reading a bevy of excellent articles on multi-hypervisor datacenters, I thought I’d put pen to paper with my own thoughts on the subject.  This article by Joe Onisick will serve as a primer to this discussion.  Not only because it was recently written, but because it does an excellent job at fairly laying out the arguments on both sides of the issue.  The article mentions three justifications organizations often use for deploying multiple hypervisors in their datacenter.  These are, 1) cost, 2) leverage and 3) lock-in avoidance.  I am in complete agreement that 2 and 3 are poor reasons to deploy multiple hypervisors, however, my disagrement on #1 is what I’d like to discuss with this post.

The discussion on the validity of multi-hypervisor environments has been going on for several years now.  Steve Kaplan wrote an excellent article on this subject back in 2010 that mentions the ongoing debate at that time and discussions on this subject pre-date even that post.  The recent acquisition of DynamicOps by VMware has made this a popular topic again and a slew of articles have been written covering the subject.  Most of these articles seem to agree on a few things –  First, despite what’s best for them, multi-hypervisor environments are increasing across organizations and service providers.  Secondly, cost is usually the deciding factor in deploying multiple hypervisors, but this is not a good reason because you’ll spend more money managing the environment and training your engineers than you saved on the cost of the alternative hypervisor.  Third, deploying multiple hypervisors in this way doesn’t allow you to move to a truly “private cloud” infrastructure.  You now have two hypervisors and need two DR plans, two different deployment methods and two different management models.  Let’s take each of these arguments against cost in turn and see how they hold up.

OpEx outweighs CapEx
As alluded to above, there’s really no denying that an organization can save money buying alternative hypervisors that are cheaper than VMware ESXi.  But, do those cost savings outweigh potential increases in operational expenditures now that you’re managing two separate hypervisors?  As the article by Onisick I linked to above suggests, this will vary from organization to organization.  I’d like to suggest, however, that the increase in OpEx cited by many other sources as a reason to abandon multi-hypervisor deployments is often greatly exaggerated.  Frequently cited is the increase in training costs, you have two hypervisors and now you have to send your people to two different training classes.  I don’t necessarily see that as the case.  If you’ve been trained and have a good grasp of the ESXi hypervisor, learning and administering the nuances and feature sets of another hypervisor is really not that difficult and formal training may not be necessary.  Understanding the core mechanisms of what a hypervisor is and how it works will go a long way in allowing you to manage multiple hypervisors.  And even if you did have to send your people to a one time training class, is it really all that likely that the class will outweigh the ongoing hypervisor cost savings?  If not, then you probably aren’t saving enough money to justify multiple hypervisors in the first place.  Doing a quick search, I’ve found week long XenServer training available for $5,000.  Evaluate your people, do the math and figure out the cost savings in your scenario.  Just don’t rule out multi-hypervisor environments thinking training costs will be necessarily astronomical or even essential for all of your employees.

Private Cloud
Similar to the OpEx discussion, another argument often presented against the cost saving benefits of multi-hypervisor environments is that they are harder to administer as you have to come up with separate management strategies for VMs residing on the different hypervisors.  Managing things in two separate ways, it is argued, moves away from the type of Private Cloud infrastructure most organizations should strive for.  The main problem with this argument is that it assumes you would manage all of your VMs the same way even if they were on the same hypervisor.  This is clearly false.  A couple clear examples of this are XenApp and VDI.  The way you manage these type of environments, deploy VMs, or plan DR is often vastly different than you would the rest of your server infrastructure.  And so, if there is a significant cost savings, it is these type of environments that are often good targets for alternate hypervisors.  They are good candidates for this type of environment not only because they are managed differently, regardless of hypervisor, but because they often don’t require many of the advanced features only ESXi provides.

I’m in complete agreement that having test/dev and production on separate hypervisors is a bad idea.  Testing things on a different platform than they run in production is never good.  But if you can save significant amounts of money by moving some of these systems that are managed in ways unique to your environment onto an alternate hypervisor, I’m all for it.  This may not be the best solution for every organization (or even most), but like all things, should be evaluated carefully before ruling it out or adopting it.