Last week's big virtualization news was Red Hat's purchase of Qumranet for $107 million.
By way of brief background, Qumranet has two overlapping, but somewhat independent, technology sets. The first--for which it is probably best known--is KVM, an open-source hypervisor that is in the process of being added to the Linux kernel. The other is its SolidICE virtual desktop solution that uses a back-end Linux server (virtualized with KVM) connecting to clients with the company's own Simple Protocol for Independent Computing Environments (SPICE) protocol. The virtual desktops themselves can be Windows, as well as Linux.
Some aspects of this buy are pretty straightforward and obvious. Others less so. As a result, I held off writing until I had the chance to discuss some of the specifics with Red Hat and my colleagues.
My conclusions? What seemed straightforward is straightforward. What didn't seem straightforward? Well, that's going to need some time to play out. Nonetheless, I got some good color and food for thought, which I share here.
My first observation is that virtualization remains a hot acquisition property. Now, $107 million may not seem like a huge sum. After all, Citrix bought XenSource for something closer to $500 million about a year ago. But XenSource was the well-known entity behind the Xen Open Source hypervisor project, and its commercial XenEnterprise product was gaining at least some market traction. By contrast, Qumranet is largely unknown by all but the most serious virtualization watchers--$107 million for a company whose "acquisition is not expected to contribute materially to revenue in the fiscal year ending February 28, 2009, but should add up to $20 million in revenue in the following year" has to be seen as a nice cash-out for Qumranet investors.
It seems clear that KVM was the major impetus behind Red Hat making this buy. Red Hat CTO Brian Stevens has been making favorable noises about KVM for a while. And, last June, Red Hat announced that it would be releasing an embedded hypervisor based on Xen. Red Hat prefers KVM over Xen for both technical and business reasons. I won't rehash them here (see this previous post), but suffice it to say that KVM plays a key role in Red Hat's OS strategy. Given that, and given how virtualization-oriented companies are being gobbled up at a torrid pace, Red Hat probably felt that there was considerable risk in not having some level of control over its prime virtualization asset--especially as almost every major Red Hat competitor does have at least some degree of such control.
Given that, it's tempting to suggest that Qumranet's desktop products just came along for the ride.
In contrast to Novell (with SUSE) and, especially, Canonical (with Ubuntu), Red Hat has never shown much of an interest in the client side of computing. True, virtual desktop infrastructure (VDI) clients run on a virtualized server; they're basically VMs that get delivered to a thin client or other client endpoint rather than "fat client" Linux desktops as they've been most commonly promoted. But, in some ways, this would seem to make the technology even a worse fit for Red Hat, given that the vast majority of deployed virtual desktops run Microsoft Windows, whatever the back-end infrastructure delivering them is.
My impression is that even Red Hat isn't certain quite how the desktop end of things will play out. On the one hand, it's clearly less of a clean fit than is KVM. At the same time, there's more than one reason to think that VDI and Red Hat aren't exactly oil and water.
- VDI is a hot technology area, and Qumranet's products are, by many accounts, solid offerings.
- As an established data center infrastructure software player, Red Hat is much better positioned to bring VDI to market than a start-up selling only VDI.
- In general, pretty much all the major server virtualization and operating system vendors seem to have accepted that they need to display at least a base level of interoperability and compatibility. (Thus, Windows and Linux guests have to play with pretty much every virtualization platform whether Windows-based, Linux-based, or something else.)
- It is at least Red Hat's hope that general client computing trends will make Microsoft's current desktop dominance a less compelling factor as more computing moves into the network.
So, yes, the obvious reason for Red Hat to do this deal--KVM--does indeed appear to have been the main reason. But a number of folks within Red Hat, are genuinely excited about leveraging Qumranet's VDI assets as well.
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.
- prev
- 1
- next





