Why Multi-Hypervisor Support is Important

I found myself caught up recently in a Twitter storm over why, or why not, multi-hypervisor support in Cloud, Automation, and Management software is important. The proponents were positioned on the side of cost, and the detractors were against the complexity such a solution introduces. Multi-Hypervisor support is important for 2 reasons: managing costs, and reducing vendor lock-in.

Managing Costs

One of the big reasons enterprises are clamoring for this feature is the increasing cost of virtualization. Ziff Davis estimates the budgeted cost of virtualization increased 17% in 2011 and will increase another 8% in 2012 (pdf report). This increase in budget is of course directly correlated to the significant trend in virtualization adoption, but it also quickly becomes a sore point for CIOs, as this increase in budget needs to somehow be funded. This increased demand has CIOs looking for other options in the Hypervisor space, such as Citrix’s Xen Server. Additionally, organizations with enterprise agreements – of which there are many – are being courted by Microsoft to use Microsoft’s HyperV platform for free. Of course, “free” is relative, and there are plenty of hidden costs with a free hypervisor, but from a purely budgetary perspective, free is attractive for many CIOs.

Another reason for this increased budgetary expense is VMware exploiting their strong market position. Off the record, CIOs have told me that renewals are becoming increasingly expensive and difficult with VMware. Anecdotes abound on blogs and the Internet over the costly upgrade and renewal process associated with the licensing of VMware VSphere.

Reducing Lock-in

This leveraging of VMware’s market position has made many CIOs realize one key point; they find themselves locked into one particular platform with no secondary plan. In economics this is known as a “Hold-Up Problem” (yes like “Stick’em Up Mr. CIO.”) This fear was increased when VMware introduced its latest revision, VSphere 5. As part of the product introduction, VMware changed its licensing model to be based not only on CPUs of host systems, but also the RAM that would be available to the running virtual machines.

As servers become more and more dense (more cores, more memory), they can, in theory, run more virtualized guests. VMware most likely envisioned a future where companies would decrease their license spend as server density increases, and thus rolled out the new licensing plan. But the plan backfired. VMware customers revolted, dubbing the new licensing model vTax, and many CIOs woke up to the risk of being at the mercy of their virtualization vendor. Eventually VMware relented and revised their new vRAM licensing model to be more generous, but the snowball had already been pushed down the hill. Enterprises are now looking more seriously at alternative hypervisors.


Multiple hypervisor platforms increase complexity; there’s no way around that. But so does having multiple operating systems, multiple application server platforms, multiple hardware vendors, etc. IT organizations have figured out how to overcome the complexity that a new platform introduces, and IT has managed to survive.

Cynicism aside, the level of complexity can be reduced if operations teams are operating effectively. First, basic knowledge of one hypervisor platform can speed adoption of the new platform. For instance, a competent VMware Administrator should have knowledge of Clusters, Data Stores, Hosts, and Guests and how those systems interact. The same concepts exist in Citrix Xen Server (albeit with different names), and this base knowledge can be leveraged to quickly ramp up on the new technology. If organizations have competent staff running their virtualization environments, they should be able to quickly ramp up on new technologies. If they aren’t then you might want to reevaluate your staffing plans.

Second, solutions exist that are multiple hypervisor aware; the key is how you use them. BMC’s own Cloud Lifecycle Management supports VMware and Citrix, BMC’s BladeLogic supports four x86 hypervisors and two Unix hypervisors, and Open Source solutions such as OpenStack supports multiple hypervisors. In using one of these solutions, you need to ensure that you are abstracting on the correct level.

Say for instance you wish to deploy MySQL servers to both a Xen environment and a VMware environment. Traditional, single hypervisor organizations with no automation would build a template containing all the software preinstalled. New instances are easy – point, click, clone. With multi-hypervisors you need to abstract one layer up, on the automation layer. You build basic templates in Xen and VMware, and then you build a common package in your automation solution to deploy MySQL to the new instance. As a side effect, you now have a package that can be deployed to virtually any server whenever you need a new MySQL installation. Complexity isn’t necessarily increased; the work is just moved to a different part of the operations stack. And in the end, your operations teams need to be moving towards this better operating model. Multi-hypervisor support simply accelerates this change.

In the end, multi-hypervisor support is becoming a larger and larger part of the enterprise’s playbook. It may initially seem to introduce complexity, but this perceived complexity can be overcome by adjusting your operations models. The scare that VMware introduced into CIOs dreams this past summer has helped to accelerate organizations multi-hypervisor goals. Whether you agree with it or not, more and more vendors will (or are) emulate BMC’s support of multiple hypervisors as more and more CIOs demand it.

For more on this discussion, and more viewpoints you can check out these Blog Posts:



Why Enterprises Will Force Down the Cost of Virtualization by Mark Thiele

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

Share This Post