I spent the past couple of days at the Red Hat Summit in Boston. Good-sized crowd--over 1,500 and more than Red Hat expected I gather. The two major topics that I found most interesting at the event were Real-Time Linux and embedded KVM-based virtualization. I'll cover Real-Time in a future post; here's my take on Red Hat's KVM announcement.
CNET News.com's Andrew Donoghue has more details, but basically Red Hat is releasing--into beta test--a small (< 64 MB) standalone hypervisor based on the KVM project. The idea is that users (or system makers) will be able to load this hypervisor into a flash memory device. A system then booting off this device will go straight into the hypervisor and be ready to start creating virtual machines and loading guest operating systems without any further preparation.
Red Hat's been a fan of KVM for a while. There are a couple of major reasons for this: one business, one technical. Both involve Xen, the Open Source hypervisor project that underpins most server virtualization on Linux today.
The business reason is that, while Red Hat contributes to and works on Xen, competitors are far more associated with the project. Novell, the owners of the only other major enterprise Linux distribution, ran especially hard with Xen early on. And Citrix--not a direct competitor but certainly a major virtualization player--bought XenSource, the commercial entity formed by Xen's creators.
From a technical perspective, Red Hat's issue is that it's hard to keep Xen and the Linux kernel in sync. Xen's a standalone hypervisor layer but it has deeply invasive hooks into the Linux kernel and, therefore, keeping the two working together takes a lot of development and testing effort. It's a bit reminiscent of how new versions of the VERITAS filesystem had to be carefully matched to new versions of Solaris or HP-UX.
By contrast, KVM is kernel-based. This means that it is actually part and parcel of the Linux kernel rather than a quasi-independent piece of software.
Red Hat's embedded KVM hypervisor is actually a stripped down version of Fedora, Red Hat's community version of Linux. Why not Red Hat Enterprise Linux? Well, for one thing, getting things down to a reasonable size means taking lots of components not needed for a hypervisor out of the distribution. A minimalist RHEL wouldn't be RHEL. Furthermore, Fedora incorporates kernel changes faster than RHEL, which speeds up support for new hardware and the like.
It's worth noting here that a standalone hypervisor is an operating system that also incorporates a virtual machine monitor in some way and a means to manage virtual machines. It differs from a conventional operating system in what it doesn't do; it doesn't provide the interfaces required by programs to run.
However, in addition to supporting programs running on top of it, Linux also offers a wide breadth of hardware support, sophisticated memory management, scheduling and the like. Thus, kernel-based virtualization effectively gets a lot of capabilities for "free" that otherwise have to be developed for and added to an independently-developed standalone hypervisor.
Although Red Hat will continue to work on and contribute to Xen, KVM is clearly its strategic direction. Using an API (application programming interface) called libvirt, Red Hat plans to abstract low-level virtualization so that the choice of hypervisor is transparent to largely transparent to management software.
KVM is arguably late to the virtualization game. However the interest that it's garnering--and its adoption by a heavy hitter like Red Hat--is just another indication that we're fundamentally still in the early days of a virtualized world.