Citrix Systems is acquiring XenSource, whose founders helped develop the open-source Xen hypervsior, for USD 500 million in a move that caps a significant week in the development of virtualization technology. The XenSource acquisition, which both companies announced Aug. 15, comes just a day after VMware, which has long been the dominant player in the x86 virtualization market, announced an initial public offering of 33 million shares of stock. By the end of its first day of trading, the company's stock closed at almost USD 51 a share.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-11-05
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.
Member since:2005-07-10
Do you really think KVM is the right solution? I don't think so. KVM depends heavily on Linux so it has a large foot print in the name of Linux. Each individual VM runs inside a linux process so I don't know how strong isolation or good shceduling you get.
KVM lacks good SMP support as well as good live migration. KVM is more suitable for light-weight virtualization needs like on desktop.
But if you want rock-solid and enterprise level virtualization then you need a hypervisor. This is the reason Microsoft is building a hypervisor for enterprise ignoring their own products Virtual Server which works like KVM.
In future their will be DMA remapping support and device assignment, you would want to have a strong isolation between multiple VMs so you can safely assign hardware resources to them.
Btw XEN not in Linux is due to some kernel maintainer's bullshit. XEN is an excellent project (far ahead of it's competition). Redhat knows that and that is why they included it in their OS. But the politics of kernel developers is preventing it to be as mainstream.
Member since:2005-07-10
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?
Member since:2005-07-08
Yes, I prefer the drivers to be inside the hypervisor. Wherever the bare metal drivers are located in a hardware virtualization solution, they are a single point of failure. So we might as well refrain from reinventing the wheel by keeping them at the bottom of the stack.
Nobody likes to write drivers. There's a ridiculous amount of hardware out there to support. The code is tedious and error-prone. Drivers are the usual suspect when anything goes wrong. This is an area where we shouldn't be replicating work. It's too big and too important. Drivers belong on the bottom of the stack where we can find common ground and cooperate.
I can't stress enough how much we need to cooperate on drivers. We need high-quality free software drivers for the vast majority of devices in the field. They need to be developed, tested, and distributed as a coherent and interoperable unit. The drivers must remain maintainable when developers and manufactures disappear.
Linux is the industry's largest such collection of drivers. Any individual or business can contribute, and its drivers are guaranteed to remain free under the GPL. Linux is the closest we've come to addressing the daunting challenge of comprehensive hardware support without depending on the limited attention span of the hardware vendors.
Hardware virtualization will inevitably lead to OS proliferation. The next decade will see everybody from Sony to SAP introducing their own native runtime environments for packaging their warez. So we really want these DRM and middleware vendors messing with complexities of bare metal? No, we want to present a generic, idealized virtual driver model that keeps things simple and isolates the system from bugs in virtual drivers.
Besides, it isn't possible to guarantee full isolation if multiple guests have direct access to the hardware. A driver bug in one guest can bring down the others, which is a big virtualization faux pas. Like it or not, the device drivers are a single point of failure in any hardware virtualization solution. It doesn't matter whether there's one privileged guest, N privileged guests, or zero privileged guests.
With this in mind, it's clear that the best solution is to have zero privileged guests. Let the hypervisor abstract all of the functionality that is unavoidably exposed as a single point of failure. Virtualized hardware makes OS development vastly easier, leading to innovative new designs and implementations.
Hardware virtualization is going be badly abused by misguided commercial software vendors. We have to draw the line somewhere. We can't just have a task switcher for grotesque monolithic "apperating systems". We have to have a sensible abstraction that insulates our hardware from these beasts of questionable quality.
In order to maintain the sanctity and sanity of our computers against the onslaught of downward integration, we have to keep the drivers in the hypervisor. Please, please think of the hardware.
Edited 2007-08-16 06:12
Member since:
2005-07-08
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.