Original URL: https://www.theregister.com/2012/01/18/redhat_rhev_3_hypervisor/
Red Hat guns for VMware with RHEV 3.0
Linux virtualization – that's Shadowman's home turf
Posted in SaaS, 18th January 2012 23:35 GMT
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.
Scaling fatter memory and more cores
Thanks to RHEV 3.0 being based on RHEL 6.2, the free-standing hypervisor can support up to 160 cores, which is the maximum supported in an eight-way, ten-core Xeon E7 server these days. The RHEV 3.0 beta was based on RHEL 6.1, which topped out at 128 cores, and RHEV 2.2 topped out at 96 cores. A single instance of the RHEV 3.0 hypervisor can, in theory, span as many as 4,096 cores.
In terms of memory addressable by the hypervisor, RHEV 3.0 tops out at 2TB, double the limit of RHEV 2.2, but lower than the 64TB theoretical limit embedded in the hypervisor's design. In terms of guests, RHEV 3.0 partitions can span as many as 64 virtual cores (which can be physical cores or threads if you are using Intel's HyperThreading) and up to 512GB of virtual memory. That's four times the cores and twice the main memory of RHEV 2.2, but that memory limit is significantly lower than what was expected.
It is all a matter of what has been tested and certified by Red Hat so far. The guest partition for the underlying RHEV can, in theory, span the entire theoretical server of 4,096 virtual cores and 64TB of virtual memory, should some server maker actually build such a box.
Thadani tipped his hand a little bit in his presentation, showing how RHEV 3.0 stacked up against VMware's ESXi 5.0, showing the expected limits coming with a future RHEV release, presumably 3.1, which is due this summer:
RHEV 3 versus VMware ESX 5 maximums (click to enlarge)
It looks like that future RHEV 3.1 will support 1,280 cores – which is coincidentally half the number on a fully loaded Silicon Graphics Altix UV 1000 shared memory supercomputer, which SGI has been pitching as a big bad Windows box. It looks like host machines with that future RHEV release will support 8TB of main memory and guests will support up to 3.5TB of virtual memory.
Among the many important features in RHEV 3.0, support for transparent huge pages is a big one, which allows for the hypervisor to dynamically create, destroy and swap huge pages, which is important for heavily loaded servers running lots of virtual machines. The hypervisor also includes the X2apic virtual interrupt controller, which reduces guest overhead, and sVirt, which brings mandatory access control to hypervisors and their guests.
RHEV 3.0 also supports vhost-net, which moves the network stack from the Linux userspace into the Linux kernel, which boosts network throughput, lowers latency, and cuts back on context switches and VM exits on virtual machines. Improvements in asynchronous I/O can yield as much as a 20 per cent boost in performance on I/O heavy workloads such as databases.
The new hypervisor also sports a new BIOS-alike text-based interface, the use of local disks to store hypervisors and VMs (instead of on shared storage such as Fibre Channel and iSCSI SANs), has an embedded version of Jaspersoft's open source JasperReports Server reporting software, and a tech preview a new Web administration console for Windows users and a Linux command line interface, based on Python, for scripting and automation.
With RHEV Manager 2.2, the control freak was certified to babysit 100 servers against a theoretical limit of 400 servers. With RHEV 3.0 Manager, the tested limit is up to 200 host servers for a single control freak. In addition to the expanded juggling capability, RHEV Manager has a new RESTful API set, a power user portal that offers more options than the prior self-service portal for end users, but less than what server admins get to see in the full-on screens.
The one thing that has not changed between RHEV 2.2 and RHEV 3.0 is the price of the hypervisor's support contract from Red Hat. RHEV costs $499 per socket per year on servers with standard business hour support and $749 per socket per year for 24x7 premium support. Unlike VMware, Red Hat is not charging for virtual memory and RHEV Manager is bundled into the support contract. ®