Red Hat guns for VMware with RHEV 3.0
Linux virtualization – that's Shadowman's home turf
Red Hat has built a $1bn company, more or less, predicated on the idea that open source Linux is cheaper than Windows or Unix and that open source Java application servers are cheaper than commercial alternatives like WebLogic and WebSphere.
For two years now, Red Hat has been trying to convince the world that it has a chance to take on x86 server virtualization juggernaut VMware, to little avail. But with the advent of Red Hat Enterprise Virtualization 3.0, and a future upgrade planned later this year, Red Hat has a much better chance of denting VMware.
But don't get the wrong idea. This will be a protracted and difficult fight. Red Hat is starting out with thousands of customers and needs several orders of magnitude more to be a real virtualization player.
The presentations given by the top hats at Red Hat on Wednesday at its "Virtualization Experience" briefing could be summed up thus:
RHEV 3.0, which is based on the KVM hypervisor championed by the company - as well as Linux rivals Canonical and SUSE Linux, is open source and more importantly, part of the Linux kernel. It therefore benefits from all of the advances that thousands of coders the world over are stuffing into that kernel and its related networking stacks and file systems. More importantly, it costs less money to support than VMware's vSphere Enterprise stack and its ESXi 5.0 hypervisor and has reached feature parity, in most respects but certainly not all, with that software.
Rather than think that it can knock VMware out of the data center, where it predominantly supports virtualized instances of Windows Server operating systems, Red Hat has figured out that it has to learn to co-exist. By working with ESXi and to a certain extent Xen, the other open source hypervisor that is controlled by Citrix Systems and that Red Hat was formerly in love with, and Hyper-V, Microsoft's hypervisor for Windows and somewhat crippled Linux instances that was developed in part with help from Citrix and Novell, which formerly owned SUSE Linux, it can prosper.
"What's exceedingly clear is there is a demand for an alternative to VMware," explained Navin Thadani, senior director of the company's virtualization business. But Thadani said that according to the survey data he has seen, 45 per cent of companies have a dual hypervisor strategy in place now (for x86 iron only presumably, since RISC, Itanium, and proprietary servers have their own hypervisors) and another 27 per cent have plans to use two x86 server hypervisors.
So Red Hat has figured out that it cannot just come in and knock out VMware with a one-two punch, but rather that it will take nine rounds of fighting and even after that, Red Hat might only be able to carve out its 20 per cent.
This is precisely what has happened in the operating system slice of the x86 server racket. Red Hat can only put so much pressure on VMware, and it is going to have to go at it obliquely at first with the new RHEV 3.0, attacking its own Enterprise Linux installed base and getting these shops to virtualize.
Thadani cited statistics from VMware CEO Paul Maritz last year when vSphere 5.0 launched, when he said that about half of the x86 servers at VMware accounts had been virtualized. By contrast, Red Hat's surveys of its Enterprise Linux base show that only about 10 per cent of the RHEL instances are running on a hypervisor of any kind. That's after two years of hammering by Red Hat, mind you.
Maybe Linux admins don't like virtualized iron? Maybe they know how to get better utilization on their machines than Windows admins? It is far more likely that in many places where Linux is installed – supercomputer clusters, Hadoop clusters, distributed messaging systems, and so on – virtualization is not as necessary as it is on other more normal enterprise workloads, and in fact can severely impede the performance of the system if you slap an abstraction layer on there.
In any event, Red Hat's best chance to take on VMware outside of its RHEL installed base where the Linux is supporting more traditional enterprise applications is to have RHEL customers get RHEV in production, test it out, see it works (or doesn't, as the case may be) and then call on Windows system managers and have them test out some Windows workloads on its commercial-grade KVM, leveraging whatever price and performance advantages – as well as the open source philosophy that is distinct from what Microsoft and VMware do to create software – to try to win a few deals.
This is how Unix carved out chunks of the proprietary server market, how Windows carved out chunks of the Unix market, and how Linux carved out parts of the Unix and Windows markets. If you want to be in the systems software game, you have to exhibit patience. Particularly if you were, as Red Hat has been doing for several years, asking RHEV customers to manage their free-standing hypervisors on a Windows-based server that was tied to Microsoft's C#. ,NET runtime, SQL Server database, and Active Directory.
RHEV 3.0 went into beta back in August 2011 and, as we learned today, is based on the "Santiago" RHEL 6.2 release that Red Hat put out back on December 6. As such, it inherits all of the feature, scalability, and performance enhancements of RHEL 6.2, including kernel and scheduler tweaks, more efficient memory management, and improvements for block I/O for storage.
Between the RHEV Manager and the RHEV Hypervisor, Red Hat says that the new stack has over 1,000 new features, enhancements, or bug fixes compared to the prior RHEV 2.2 stack, which was based on RHEL 5.5.
With RHEV 3.0, the management console has been ported from C# to Java and runs on an embedded version of the JBoss EAP 5 server; the backend for the manager is now the open source PostgreSQL 8.4 database instead of SQL Server. Customers can authenticate users and resources through Microsoft's Active Director or Red Hat IPA as they see fit.
RHEV 3.0 includes a migration tool that can suck the data out of SQL Server running on the Windows box supporting RHEV Manager 2.2 and spit it back into the PostgreSQL database running on a RHEL server and port over to RHEV Manager 3.0 without having to take down any of the running VMs.