At the Linux Foundation’s Collaboration Summit in San Francisco last week, executive director Jim Zemlin encouraged vendors and developers to standardize their virtualization activities around KVM—not Xen. This whole Xen vs. KVM debate is getting annoying, but first off, this “news” isn’t news: there shouldn’t be any shockwaves from this late-in-coming statement. Why? Because KVM has been officially included in the Linux kernel since early 2007. So it shouldn’t be any surprise that The Foundation (that has a nice Big Brother ring to it, no?) is encouraging KVM adoption.
But the crux of the issue is really around why The Foundation chose KVM in the first place. It’s simple: KVM = Linux; Xen = Xen (that is, a purpose-built hypervisor derived from Linux). In fact, guess what KVM stands for? Kernel virtual machine. So if I were going to include one in the Linux kernel, which would I choose…hmm… While that seems like an easy decision, there are consequences. For starters, Xen is the more widely-adopted platform that already has abundant commercial support and an active open-source community. Second, KVM is not a true hypervisor: it’s a hosted VMM. I don’t know why the Linux zealots are fighting this one so much, but they argue it is a hypervisor because it gives guest operating systems direct access to the hardware. Fine, I’ll make a concession: KVM gives Linux hypervisor-like functionality. But, it’s not a true hypervisor because it requires Linux. It uses the regular Linux scheduler and memory management. So, if you want to load up KVM, you have to boot up Linux—there’s no two ways around it.
What really annoys me, though, is the The Foundation’s attitude towards virtualization. Take this comment from a Linux coder at IBM, which didn’t come from The Foundation’s Summit, but pretty much sum’s up its general philosophy:
I trust Linux to run on my dvd player, my laptop, and to run on the servers that manage my 401k. Is virtualization so much harder than every other problem in the industry that Linux is somehow incompatible of doing it well on its own? Of course not. Virtualization is actually quite simple compared to things like real-time.
Wow. If Microsoft has ever been criticized for trying to make Windows do everything, then The Foundation should be criticized ten-fold since they're doing the same thing but under the auspices of being a "non-profit consortium." Of course, the undoing of the Linux coder’s logic is the last line in his very own comment. If virtualization is a “simple” workload, than why do I need to boot full-fledged Linux to get it? More importantly, why would I want to? While running virtualization as just another application workload on top of an OS might be fine for dev/test, it’s not fine for production workloads. Servers that are part of virtualization resource pools are not going to be doing anything other than hosting guest VMs because I want to eek as much performance out of those servers as possible. To ensure that, the only thing running between my OS workloads and bare-metal hardware should be a thin, purpose-built hypervisor. Why would I want the performance hit and increased attack surface that comes with booting a whole operating system if I don’t need it?
MS understands this, which is why Hyper-V is a true hypervisor as opposed to it’s Type-2 VMM predecessor, Virtual Server. Dell and HP understand this, which is why they give customers the option of ordering servers with XenServer or ESX pre-installed. Organizations understand this, which is why they’ve standardized around true hypervisors like XenServer, ESX and Hyper-V. Everyone seems to understand this except The Foundation, which seems to believe that all workloads are best run as just another application stack. They’re not. Don’t get me wrong, The Foundation’s Swiss Army Knife mentality can be appropriate—and even ideal—for many types of workloads. But if you give me a nail, I want a hammer—not some Frankenstein “utility” tool.
Posted
Apr 17 2009, 12:48 AM
by
Brad Moczik
Follow Me on Twitter
Did you enjoy this article? If yes, then subscribe to our

or