Xen and the Art of Demystification
In my various virtualization-related Web wanderings, I come across a lot of confusion about Xen; what it is, who uses it, what its place is in the virtualization market. When I first started diving into this arena, I was similarly confused.
Well, after much research and many interviews, I believe I have a handle on Xen, and will try to clear up some of the misinformation out there.
First, Xen is an open source hypervisor. It's maintained by the Xen Project, which houses the source code and remains the home of the Xen community. It was originally developed by the company XenSource, before XenSource was bought by Citrix last year for $500 million. What that means is that XenSource, as a product, no longer exists; the Citrix version is now called XenServer.
Xen is still going strong, though; in fact, it's healthier than ever, given the cash infusion from Citrix after the acquisition.
Simon Crosby, former CTO of XenSource and now CTO of the Virtualization and Management Division at Citrix, emphasized to me that Citrix absolutely does not interfere with the Xen project. "It's very important that there is a church-state separation there," he says. Xen is "still community-driven ... and guided by an advisory board." (As an aside, Crosby is one of the founding fathers of the new virtualization industry. His blog is an absolute must-read for anyone who wants to know what's really going on in this space.)
Being open source, Xen can be used by anybody, or any company, that wants it, as long as they abide by the GNU General Public License (GPL2). And, in fact, many virtualization vendors are using Xen. They include Citrix (of course), Virtual Iron, Sun, Red Hat, Novell and others. They differ from companies that have built a closed, proprietary hypervisor like VMware, Parallels and Microsoft (more on Redmond in a moment).
Xen is a trademarked name and can only be used if a company follows certain rules on how Xen is incorporated into their products. Basically, according to Crosby, "The interface between a guest and the hypervisor is really what defines that whether [a hypervisor] is or isn't Xen. If a product derives from the Xen codebase and is compatible in key interfaces, it can be described" as a Xen hypervisor. How vendors the use the Xen hypervisor differ is in what they build on top of Xen; for instance, what type of migration technology a company uses to move virtual machines from one physical server to another.
Another common misconception surrounding Xen is that Microsoft's new hypervisor, Hyper-V, is based on Xen technology. This is simply false. Xen and Hyper-V were "built totally separately," says Mike Neil, Microsoft's general manager for virtualization. "There's no common lineage in technology."
Crosby affirms Neil's statement. "Hyper-V is entirely Microsoft-created codebase ... there is absolutely no Xen in Hyper-V."
The confusion about Hyper-V's roots may arise from their similar architectures. Notes Neil, "From an architectural standpoint, we and Xen have taken the same tack of building a very thin hypervisor, and then moving functionality into partitions -- into the virtual machines."
Again, Crosby and Neil are in agreement. "Hyper-V shares core architectural principals" with Xen, he says. "But their implementation is entirely different. They [have] different APIs; their functions and protocols are different. But architecturally they are very similar."
Citrix and Microsoft have also taken great pains to make sure their hypervisors get along. For instance, any VM created in Xen can run in a Hyper-V environment, and vice-versa. The long, productive relationship between the two software giants has transferred very nicely to their virtualization efforts. VMware, by contrast, is currently much more closed; it's a great irony that both Citrix and Microsoft, which have both taken many hits over the years for making proprietary software, have become much more open in the area of virtualization.
I hope this makes sense, and that you get some use out of it. It's complicated, but I would strongly recommend you research each of the different types of hypervisors to see the benefits and drawbacks of each before deciding on a solution. And your solution may involve using more than one type of hypervisor.
Posted by Keith Ward on 02/22/2008 at 12:48 PM