Blame it on the “vRam tax.” At worldwide disability insurance provider Unum Group Inc., VMware was long established as the company’s hypervisor vendor. But when VMware introduced the much-maligned vRam licensing structure for vSphere, Curtis Gunderson, Unum’s director of virtualization architecture, was tasked with looking at other potential virtualization vendors for the 10,000-person company.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
“This started the first real multi-hypervisor review as a strategy, versus a single-vendor selection process,” Gunderson said.
In pursuing a multi-hypervisor environment, Chattanooga, Tenn.-based Unum was looking to both avoid vendor lock-in and increase the mobility of its workloads. Having vendors compete for the business and supply solutions with common components would allow for more flexibility across multiple vendor platforms—or at least that was the thinking.
Certainly, the approach seemed especially suited to vetting hypervisor software because—despite a trend toward feature parity across hypervisor vendors—all hypervisors are not created equal for all situations.
As Gunderson discovered and other experts attest, however, the strategy should be pursued with caution. While a multi-vendor approach in theory offers substantial benefits over a single-vendor platform, in reality working with more than one vendor and negotiating costs across multiple vendors doesn’t always pay dividends.
Judging whether multi-hypervisor environments make cents
One of the biggest problems with making the multi-hypervisor approach work financially is that the capital-expense savings garnered upfront by having vendors compete on price wind up being negated by ensuing operational expenses, according to David Bartoletti, an analyst at Cambridge, Mass.-based Forrester Research Inc. If you managed to use the threat of Microsoft to bring VMware’s prices down, at the end of the day you still have to manage the hypervisor platforms you bought, he said.
“If you have a strong Microsoft team that’s very familiar with Windows server environments and Microsoft management tools like System Center, then it’s probably not much of an impact to bring Hyper-V into that environment, because you have the management skills,” Bartoletti said. “On the other hand, if your team is very skilled in VMware and you’ve been doing a lot of VMware virtualization for a long time, you’ll take on a lot of operational overhead using another tool to manage [another hypervisor].”
The real question has to be: What do you really want to accomplish with a multi-hypervisor strategy?
Curtis Gunderson, director of virtualization architecture, Unum Group Inc.
Gunderson doesn’t disagree. His consideration of moving to a multi-hypervisor environment was part of a cost-savings directive. Had it not been, it wouldn’t have necessarily been something he’d have considered.
Gunderson and his team have deeply integrated VMware into a lot of Unum’s operations, and his team’s VMware experience is very mature. It was difficult, he said, to make VMware more of a “generic” hypervisor and transform processes back out to external management tools.
“I say mature, mostly because we integrate with vCenter and use virtual machine (VM)-level backup tools; we also use VMware distributed networking components and some of their additional products like View, SRM and vCloud Director,” he said. “We have limited staff to either do all of this on other platforms for other hypervisors or rip it out and reengineer processes to make VMware more streamlined.”
In lab tests, his team compared a generic VMware environment, stripped of any customization, with kernel-based virtual machine (KVM) and Hyper-V environments to assess transferability between vendors.
They found that despite feature parity among the hypervisors at the “least common denominator,” a multi-vendor approach doesn’t provide for seamless migration between platforms without significant customer and process impact. Another finding was that the process work to make the hypervisor a commodity would be too costly. Finally, they learned that if a different hypervisor had to be introduced for a specific tool or product, it would be engineered specifically for that solution without consideration for cross-platform migration.
“The real question has to be: What do you really want to accomplish with a multi-hypervisor strategy?” Gunderson said. “I think a multi-hypervisor strategy is great, if you intend on a wholesale switch between hypervisors or hypervisor differentiation/isolation by platform. I don’t’ see it working well if you have long-term VM needs, specific service-class migration or need consistent processes across all platforms.”
Vendor flexibility ‘completely overstated’
Indeed, CIOs who answer that question with vendor flexibility, might want to reconsider, said Chris Wolf, an analyst at Stamford, Conn.-based Gartner Inc. In his experience, vendor flexibility is “completely overstated” in a multi-hypervisor environment.
More about virtualization strategy
Storage technologies making Data Center as a Service viable
Virtualization: Realizing the rewards, avoiding the pitfalls
Virtualization management tips from the frontlines
“When you have fewer parts and fewer things you’re trying to orchestrate, it’s cheaper and it’s easier,” Wolf said. “That’s indisputable, and beyond that, service providers have proven that’s the best model for scale and cost.”
That message isn’t often heard, Wolf said, due the cacophony of voices that stand to profit from selling complexity: vendors, consultants and, yes, analysts.
“The bottom line is there’s a big ecosystem that thrives off complexity and that ecosystem is always going to encourage the customer to have a more complex environment than they need,” Wolf said.
While Wolf maintains a single-hypervisor approach is best, that shouldn’t translate into using a single vendor throughout the stack. The stack is where a multi-vendor approach is advisable, he said.
“If you’re using a single hypervisor, you don’t have to use the same vendor for management,” Wolf said. “[You can use]a management vendor who can work across multiple hypervisors so you have flexibility in the stack in terms of being able to remove a vendor if you need to.”
Vendors often focus on converting the VM from one hypervisor to another, and that’s not the real hurdle, Wolf said.
“It’s your entire management stack that makes this difficult because your security tools, your backup tools and your monitoring tools often connect directly into a specific hypervisor’s API set,” Wolf said. “It’s not just converting the VM when I go from one hypervisor to another. I need to make sure all of my management and operational software works the same in the new hypervisor environment.”
The right tools for the job
Technology has matured to the point that most hypervisors have similar core functionality. As Bartoletti put it, the hypervisor wars are pretty much over. A few years ago, VMware was so far ahead of the other hypervisor platforms in terms of functionality there really wasn’t an option to run anything else. Today, feature parity has essentially been reached and the real concern has shifted to management capabilities.
“Heterogeneous virtualization is here, so go ahead and use multiple hypervisors and you’ll get pretty much the same performance out of all of them,” Bartoletti said. “You shouldn’t be worrying about a bake-off between hypervisor platforms; you should be worrying about a bake-off at the management layer. Who gives me better visibility? Who lets me manage my service levels? Who lets me make the environment be more available regardless of what hypervisor I’m running?”
That, however, is not so easy to ascertain, says Gartner’s Wolf. Backup software has to support the different hypervisors of choice. Moreover, every backup vendor will say it can support every hypervisor, and while that may be true, it’s not enough.
“When you look at the way they support hypervisors, there are considerable differences,” Wolf said. “Some will take a very legacy approach to being able to backup VMs, and that’s the case with how a lot of vendors support Red Hat KVM today: they can run an agent inside a virtual machine and back it up, but that approach is so resource-intensive that it’s actually the least favorable way you’d ever want to back up a virtual machine.”
Gunderson believes the allure of the multi-hypervisor strategy, and the reason IT leaders continue to be both enticed and challenged by the model, is the increased feature parity, as well as the tightening of cross-vendor hypervisor migration gaps. Third-party management tools, and to a large degree major-vendor hypervisor management tools, are evolving toward allowing a single tool to manage multiple environments, he said.
“As this occurs, the redundancy in operational overhead continues to be reduced, but it isn’t quite there,” Gunderson said. “When it gets there, one would be able to reduce management tool costs for vendor specific tools, which can be expensive.”
Some IT environments call for multi-hypervisors
For some companies, a multi-hypervisor environment is a necessity, as is the case at Amsterdam-based hosting company Schuberg Philis B.V. A diverse customer base has led the company to run many hypervisors, said Hugo Trippaers, mission-critical engineer, including both Citrix XenServer and VMware, and soon KVM and Oracle VM
Serving energy trading companies, banks, online retailers and other industries means dealing with a wide selection of applications, Trippaers said—and being able to pick the right tools to stay in control of application management. Each hypervisor has its own set of capabilities, allowing the company to make the best choice for a given situation. For example, Trippaers was able to use Nicira’s network virtualization software in the company’s Citrix CloudStack because XenServer had built in support for that technology.
“If we hadn’t looked beyond our once-standard VMware solution, we would’ve missed out on technology that really benefitted our deployment,” Trippaers said. And, in this case, the dollars and cents makes sense. “The different hypervisors have their cost, which we can balance against the features they provide. Why pay for features you’re not going to use?”
That said, there are downsides, Trippaers acknowledged. Every hypervisor he’s worked with has had its share of problems, from hardware compatibility issues to software bugs.
Introducing a cloud management system has been key to keeping an expanding environment of hypervisors under control, Trippaers said.
“Processes that need resources from the hypervisor pool need to talk to a central system that abstracts the technology underneath so resources can be selected based on features, infrastructure can shift without impacting those processes and features can quickly be introduced,” he said.
Other scenarios in which multi-hypervisors can be advantageous are places where disaster recovery and centralized management aren’t required—a separate wing of development or a company’s branch office with its own IT staff, said Gartner’s Wolf.
“If management is separate and you can save money and don’t ever have to worry about moving VMs and management silos, in these cases multi-hypervisors may be a good decision.”
Let us know what you think about the story; email Karen Goulart, Features Writer.