OSNews

"Well, time to fork Xen.
Once Citrix, that Microsoft's bitch, takes over Xen, they'll try to cripple or kill it for sure."

You can take this to the bank: Microsoft is extremely interested in seeing Xen succeed because it validates their own efforts to incorporate a virtual machine monitor into the OS (one, that I might add, is architecturally very similar to Xen). This is critical to Microsoft’s efforts to combat VMWare and their potential argument that Microsoft is bundling virtualization software with their product. By both Windows AND major Linux distributions adopting Xen, Microsoft gets all of the above AND a competitor that has cooperated in making an interoperable solution (Microsoft and Xen are both working on interoperable hypercall functionality, VHD format, etc.).

So no, Xen, in the near and distant future, is not going to end up dead or crippled (probably quite the opposite). It is, however, a major component in Microsoft’s gambit to marginalize VMWare and bundle virtualization with their product. It might be an unholy alliance, but it’s an alliance nonetheless.

Well, to be brutally honest, Xen was crippled by design from the very start. XenSource pushed against the Xen community to replace a relatively challenging situation with an almost insurmountable challenge. And now Citrix gets to inherit that challenge.

Of course, I'm referring to the initial decision to create the notion of a privileged guest, the Dom0, which deals directly with the hardware. Although other ports have been attempted unsuccessfully, the only viable Xen Dom0 is Linux. A heavily-modified Linux that keeps diverging from Linux as time goes on.

XenSource doesn't like tracking Linux kernel development with their out-of-tree Dom0 patchset, and there's zero future for the Xen Dom0 in the mainline kernel (although the Xen DomU has been merged). They don't like the whole idea of the Dom0, especially since it can't be Windows.

So Citrix is acquiring a company whose technical strategy is to dump Linux as its hardware abstraction layer and develop comprehensive hardware support on its own. VMware seems quite loony these days, but at least their strategy is technically feasible. They already have a "fat hypervisor" with reasonably broad hardware support.

Linux also has a fat hypervisor with very broad hardware support. At least three of them, in fact. One of them is a hardware-assisted full virtualization solution with all the hype of Xen circa early 2005, except it's in the mainline.

You see, the Linux community has already forked Xen. It's called KVM, and it's the right technology at the right time.

butters, I have to agree with you 100% on this one. Take a look at this awesome post from the gnu libc maintainer, ulrich drepper about kvm vs xen:
http://udrepper.livejournal.com/17577.html

This is bookmarking material.

KVM seems to be learning from Xen's mistakes. A good example, Xen's live-migration features connects 2 servers on a lan via an unencrypted tcp socket. Not sure about some people, but I find the idea of transferring raw memory over the wire unsettling at best seeing as how the ssh agent could have my key in it. kvm supports ssh for live migration:
http://kvm.qumranet.com/kvmwiki/Migration

The guys at qumranet know what they are doing.

Of course, I'm referring to the initial decision to create the notion of a privileged guest, the Dom0, which deals directly with the hardware. Although other ports have been attempted unsuccessfully, the only viable Xen Dom0 is Linux. A heavily-modified Linux that keeps diverging from Linux as time goes on.
--
So would you prefer the vmware model where the drivers are inside the hypervisor? Did you consider the disadvantages in that approach?