If Hypervisor is Commodity, Why Is VMware Still on Top?

Microsoft and open-source rivals lose it in the labs

23 Apr 2015

Trevor Pott

Recent Articles Don't panic as Server 2003 rushes towards end of life Flash banishes the spectre of the unrecoverable data error Microsoft Azure or how to make the public cloud work for youThe hypervisor is a commodity. VMware's ESXi, Microsoft's Hyper-V and the open-source community's Xen and KVM are all right and proper tools for virtualising workloads. Does that mean we should all stampede away from expensive proprietary hypervisors and dine on the open-source freebies? This being IT, the answer is "it depends".

Each of these hypervisors is a bad fit for certain niches and marketing wonks at VMware are never happy when I proclaim the hypervisor a commodity, but for your everyday workload it's true. So if this is the case, why aren't KVM or Xen more popular? For that matter, why is Hyper-V which is a perfectly capable and credible hypervisor lagging so far behind ESXi?

There are technical answers to these questions, as well as economic, political and cultural ones. They all interact and they all play a part. Perhaps the most important answer to bear in mind is that quite simply first impressions matter.

Very few of us go back and continually revisit our assessments of technologies, products and services we find did not meet our needs. We did an assessment in the past, why revisit the decision? Especially if what we have to hand works.

The short answer to that question is: "Because it can save you a lot of money." Something that oddly enough doesn't actually matter to all that many people in the purchasing decision-making chain. Still, just for fun, let's give cross-comparing today's virtualisation technologies a go.

(Im)perfectly usable

Being the de facto industry standard, it's really hard not to use VMware's ESXi as a standard candle by which to judge all competitors. It's also worth noting that VMware almost always wins out on quick tests because it excels at test-lab implementations, something Hyper-V in particular is very bad at.

The key to VMware's test-lab success is that it is excellent at being a self-contained environment. A full vSphere implementation with all the management tools, virtually every feature and so forth requires little more than a pair of servers, some storage and the vCenter Server Appliance.

No domain controller is required. You don't need to set up "libraries" or other complicated fooferah in order to use an ISO image or inject a virtual machine (VM) template. The standard management tools allow you to create a VM, connect to its console, easily feed it an ISO from anywhere the system you're using can find one and go. Easy, peasy.

How about Hyper-V without System Center and as part of the GUI install of Windows Server? Is this easy? It's quite deceptive, as a matter of fact, because as soon as you're trying to use Hyper-V Server (or as part of Windows Core) it's a right pain to get going. VMware can be set up by a lobotomised monkey wigging out on bad crack, but Hyper-V server requires having the Mystical Book Of Commands to not only feed it set-up information it's supposed to have, but to work around WONTFIX bugs.

Similarly, trying to use System Center imposes a huge web of limitations and dependencies. The stupidest of them all is that console access to a VM using the Hyper-V manager in Server 2012 will let you mount an ISO to a VM and go, whereas with System Center it will only mount ISOs that are part of the System Center library.

The library, of course, can't just be any SMB or NFS share, but has to be owned by a domain-connected server that has met all the voodoo requirements. So you need a domain controller, a library server, a System Center server (or multiple, if you want to use more than SCVMM and have System Center actually work,) as well as the Hyper-V servers themselves.

Once it works, Microsoft's virtualised Rube Golbergian mindfrak works reasonably well, but it's not easy to test-lab and it's not easy to integrate into existing environments. Especially heterogeneous environments, or ones where you want the virtual servers to live out in the DMZ.

On the flip side, if you're a script junkie you can make entire data centres of Hyper-V servers dance with PowerShell. In theory, you can do this to ESXi (via PowerCLI) as well, but Microsoft's implementation has generally been more robust and the community around it that little bit broader and more active.

VMware GUI-based management tools, however, absolutely wreck Microsoft's, especially when dealing with large deployments.

This situation has led to the elevation of 5Nine to cult-like status among SMBs. It has a feature set rivalling System Center Virtual Machine Manager, but is generally cheaper. Mostly, however, it is beloved both because there is a free edition for home labs and because it provides a Hyper-V management interface not birthed in an unholy Lovecraftian dark rite has even earned it production use in some midmarket companies.

KVMKVM falls somewhere in between the two commercial behemoths. While Xen is the darling of Citrix, Amazon, Rackspace and a few others, KVM has clearly become the default open source hypervisor. This is in large part because Red Hat declared that it should be so, and thus it was.

A great example of this is any discussion involving OpenStack. When normal people talk about OpenStack they are talking about a series of open-source storage and networking projects attached to the KVM hypervisor and some management tools.

You can use OpenStack with other hypervisors, but doing so will draw some stares and mutterings of "oh, he's one of those people". Which is odd, because OpenStack is well into "people who keep pee in jars" territory all on its own, so getting finicky about the level of bizarreness when you're that far down the rabbit hole is perhaps a little counter-productive.

KVM is a perfectly decent hypervisor. It's fast, it does all the basic things you want a hypervisor to do and most of the tricky advanced stuff, too. The problem and this is true of most of the open-source world lies in actually implementing and managing the thing.

The default KVM management tools that ship with most Linux distributions are designed by people who think "esoteric uses of bash syntax" is great fun at parties. Microsoft may have infected the world with the ribbon and whatever the hell Metro was supposed to be, but virt-manager should be considered a war crime.

A list of KVM management tools can be found here. The existence of this list is both the explanation for why KVM hasn't taken over the world and the reason it is wrecking Xen.

The fact that there are so many different interfaces for KVM and that list doesn't cover even half of what's out there is KVM's Achilles' heel. It's virtually impossible to have a "shared experience" with KVM. There is no loyalty to the hypervisor itself or any of the affiliated projects. Administrators become members of the community around the management tools or virtualization appliances, and those tools eventually evolve to handle multiple hypervisors, containers, public clouds and so forth.

The best-balanced management tool on the KVM list is probably Proxmox, and like 5Nine, it's basically become a cult. The coolest is probably Mist.io, which can manage pretty much anything that needs managing all from a neat cloudy interface. Awesome possum, except for that whole "giving an American company access to the servers/cloud accounts that my entire business runs on" thing.

Xen

Xen can be summed up by visiting this page. The page is a nice, simple, clean wiki that lists various Xen management tools. At the top is a banner telling visitors "for the latest information, see the Ecosystem Directory on XenProject.org." The XenProject.org site is... well, it's not anywhere near as easy to use as that wiki.

Xen is the sort of thing that's fine and good if you have a warehouse full of PhDs and an IT budget rivaling the GDP of a small nation state. In a lot of ways it is technically superior to KVM. It's also fractious, with massively vested interests pulling the thing in a number of different directions and it suffers from a tragic lack of anything resembling centralised leadership.

For a time, Citrix was that leader, but Citrix had an uphill battle on its hands. The big US public clouds are Xen. From Amazon to Rackspace to IBM's Softlayer, there are powerful companies with vested interests in Xen. Citrix, with its focus on providing a usable Xen that customers installed in their own data centres and with Citrix's unique focus on Terminal Services and VDI was the odd man out.

Citrix is still a guiding force for Xen, but it has slowly had to cede control to the cloud behemoths. The results have been mixed. While the KVM ecosystem is absolutely exploding, Xen has really collapsed into occupying the sorts of niches that other hypervisors haven't taken over yet.

Remote application delivery and remote desktop delivery are great examples. Citrix ultimately open-sourced XenServer, but hung on to the bits that made money: everything around Citrix's core competency of VDI.

Xen and the art of hyperscale management

Similarly, Xen hangs on stubbornly at hyperscale, but mostly because "it was there first". KVM has proven itself at scale HP's Helion cloud is an example. But the Amazons of the world are not going to go tear up their investment in Xen for KVM, especially when they have such a strong say in the future of Xen, but KVM's future is largely dictated by Red Hat.

The result is two open-source hypervisors with two very different futures. KVM is evolving to become the open-source replacement for ESXi and Hyper-V. The ecosystem around it is all about commercial implementations by companies ranging from SMBs to Enterprises, and increasingly organisations looking to stand up regional clouds.

Xen is, well, Xen. It's an afterthought to a lot of companies. It is becoming its own thing used for its own purposes. Purposes that most companies aren't going to care about, which explains the lack of ecosystem interest.

This isn't to say that there aren't groups out there pushing to have Xen considered for the same applications as ESXi, Hyper-V and KVM. It's just that they're rather bad at politicking and marketing, with the predictable results of patchy and inconsistent success.

Most companies will have a good long think about ESXi versus Microsoft. Especially if they are starting a new virtualisation project or are spinning up a new company. Increasingly, KVM will be a part of that conversation, but it's still really rare to hear of Xen seriously discussed here.

On the other hand, companies that are otherwise entirely VMware or Hyper-V will absolutely bring in Citrix-based Xen servers to handle VDI deployments, treating them essentially as a separate environment from the rest of the virtualisation infrastructure.

Infrastructure solutions

ESXi, Hyper-V and KVM are infrastructure solutions. You build yourself some infrastructure made out of one of these three then load it up with VMs. But the focus is on the infrastructure itself, in no small part because of all the companies in the associated ecosystems wanting to sell you solutions to various infrastructure problems.

Xen is a point solution. If you have a specific problem, there may be a Xen-based solution, but there isn't a whole lot of "build out Xen infrastructure and then waiting to see what gets put on it". Except, you know, for virtually the entire public cloud.

ESXi, Hyper-V and KVM are at this point functionally interchangeable. Every now and again one of them experiences a generational leap in capability. Currently, VMware has the lead with the vSphere 6.0 family of products, but that won't last long.

Ultimately, it keeps coming back to those management tools. Xen has trouble bridging the gap and taking over general infrastructure because of a lack of quality management tools and confusion about licensing the ones that exist.

KVM lags Hyper-V mostly due to a historicity of bad management tools and a current state of too many management tools. Hyper-V lags ESXi because System Center was sent from hell to make us miserable.

All of which really boils down to one key take home: when it comes to hypervisors, the tech is solid all over. It's ease of use that matters and management tools, of course.