VMware and Xen clash over Linux virtualization patch (InfoWorld) [LWN.net]

InfoWorld looks at virtualization support and the Linux kernel. "It seems VMware has been working on a hypervisor-based virtualization technology, similar to Xen's, for an upcoming release of its commercial virtualization product line. Like Xen, VMware's technology will work better on Linux if the Linux kernel gives it a little help and so, like Xen, VMware has been submitting long lists of patches to the kernel developers for review and possible inclusion in the kernel. And wouldn't you know it, the Xen group's patches and VMware's patches are totally incompatible with each other." (Thanks to bjg)

to post comments

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 0:03 UTC (Wed) by drag (guest, #31333) [Link] (5 responses)

"The Xen developers' proposal, on the other hand, is 100 percent specific to Xen -- so much so that it's completely unsuitable for VMware's needs (or those of anyone else who might come along). Xen could do things VMware's way, but its developers prefer not to. Period. "

If this is true and if VMI can be used by Xen and other projects then Xen's patches loose.. and loose hard.

Kernel developers seems to always choose a generic solution vs a propriatory one.. A big example is the Linux-VFS stuff vs little individual file system (redundant) features.

Xen has no chance to win this one if they refuse to play along and push a Xen-specific solution. It just ain't going to happen. Even if their solution is technically superior.

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 0:31 UTC (Wed) by danpb (subscriber, #4831) [Link] (4 responses)

The InfoWorld article failed to mention that while the VMI kernel code is open source, it in turn relies on loading & talking to an opaque binary blob - essentially you'd load a different binary ROM to switch between different hypervisors. Binary blobs aren't haven't been all that popular in the kernel in the past so it doesn't seem clearcut that VMI wins simply by virtue of being a generic solution. The LWN kernel summit article on virtualization from a couple of weeks back mentioned an alternate proposal "paravirt_ops" which would also allow multiple hypervisors to be supported without needing a binary blob to be loaded:

http://lwn.net/Articles/191923/

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 2:04 UTC (Wed) by drag (guest, #31333) [Link] (3 responses)

Well it depends on how this binary blob talks to the kernel, I suppose. If it's like a driver or whatnot then it's bad, but if it's just a different userspace thing it won't matter so much I figure.

I don't know much about this VMI stuff.

I mean if your using a closed source hypervisor you deserve what you get, don't you?

But ya the binary blob aspects sheds new light on it. If you can do it without that and be a generic solution then that would be nice.

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 2:28 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

thick of the blob as a jump table, if you load the blob to run on bare hardware you jump to the same routine that you would have run anyway, if you load the blob to run on vmware it calls the appropriate vmware routine, if you load the blob to run on xen2 it calls the appropriate xen2 routine, etc.

all this with the same kernel binary.

the parvirt_ops that is being looked at instead lets you load a module at boot time that patches the kernel binary (in some cases, in others it populates an internal jump table)

personally I think the VMI interface sounds cleaner for users in the long run. but the fact that it was described as a 'binary blob' has tainted all discussion of it and it's not likly to be accepted as-is. however it looks like the vmware interface is going to implement this anyway, so even if xen isn't initially willing to use it it will be available for others to use (including future versions of xen)

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 16:56 UTC (Wed) by AJWM (guest, #15888) [Link] (1 responses)

> think of the blob as a jump table

Okay, so it isn't exactly a jump table? What then?

But whatever it is, the (understandable) concern is that it's binary. How about coming up with some kind of source form for it ("compiled" at load time, if necessary)? That gets around the concern that it's just an obscure bag o' bits, and also solves any potential issues with that bag not containing the right bits if the kernel, vmware, xen, or etc is modified.

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 19:54 UTC (Wed) by dlang (guest, #313) [Link]

they are saying that they expect to have the VMware VMI 'blob' be opensource (there are delays, as there always are when a company checks source to open it)

however the idea is that there would be an ABI between the hypervisor layer and the kernel itself.

this would allow the kernel and hypervisor layers to evolve independantly of each other.

so if this was in the kernel you could compile a 2.6.18 kernel to support this interface and then use it on any hypervisor with no change. you would also be able to use this kernel binary five years from now on hypervisor X that hasn't been invented yet (you may not be able to take advantage of all the features, but the ones that the 2.6.18 kernel knows how to use would still exist)

I'm nervous about the idea that has been expressed of having the kernel compile in support for each of the hypervisors that it can work with. In production systems virtual machines (like chroot sandboxes) tend to be setup and run for a long time with minimal modification. I'm afraid that the 'compile in the support for the hypervisor' will run into problems where a virtual system requires a significantly new kernel becouse there's a new hypervisor out that didn't exist at the time of the kernel you were running and so it's not possible to run that kernel on the new hypervisor.

Incompatabilities in the other direction are acceptable (requireing a new hypervisor to run a new guest kernel), and nessasary to allow for new features to be added. but unless the new hypervisor always supports the old guests you can end up in a catch-22 situation where there is no hypervisor available that can run all the guests that you want/need to run.

and just having the source available doesn't eliminate this catch-22 risk. Xen setup this exact situation with their version2 to version3 migration. you can't run version2 guests on version3 hosts or version 3 guests on version 2 hosts. Since Xen is still highly experimental they could get away with a 'flag day' change like this, but for a mainstream interface this is unacceptable (other examples of this sort of problem are udev and alsa, they have both had situations where kernel X requires version <=y and kernel x+1 requires version y+1, makeing it hard or impossible to move back and forth across the versions for testing. for udev and alsa this has been declared unacceptable, but the details of the issues are still being worked out)

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 0:10 UTC (Wed) by corbet (editor, #1) [Link] (1 responses)

FWIW, I wouldn't have posted this one. Subscribers can look at this article from the upcoming Weekly Edition for a rather different view on paravirtualization support in the kernel.

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 3:16 UTC (Wed) by oshogg (guest, #23126) [Link]

Thanks for the article. Very informative.

Osho

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 16:59 UTC (Wed) by aliguori (guest, #30636) [Link] (2 responses)

An important thing to preface this conversation with is that despite what the article claims, the Xen community and VMware are working together to sort this all out. See Steve Herrod's recent blog post and Rusty Russell's paravirt_ops work.

When you compare VMI and the Xen hcalls, you find they are quite similiar in architecture. Both ABIs use something similiar to the Linux vsyscall table. In Xen, we call it a hypercall page and it's located at a fixed address within the hypervisor space. In VMI, they call it a ROM and they store it in the option rom space in legacy BIOS memory. Because of it's location, the guest has to copy it somewhere else before it begins executing it.

The verbage is unfortunate because people tend to think that the ROM is somehow different than the hypercall page. They aren't. It's the same basic idea. I actually like putting the hypercall page in option ROM space but it would take a considerably amount of Xen refactoring...

As for the actually hypercalls, there is quite a difference between the two. VMI starts with the lowest level operations possible (think of it as a software version of hardware virtualization). It then adds a handful of optimizations to get performance up to native.

Xen, on the other hand, co-designed the hypercall API with Linux. This means it's much larger than the VMI API and there are perhaps quite a few things in it that there shouldn't be.

Anyway, the paravirt_ops patch, which is what both are converging to, it similiar to VMI in terms of what API's it exposes. The key difference though is that it's an API within Linux. This means that the Linux can support any number of ABIs (via a hypercall page like Xen, or a VMI option ROM).

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 9, 2006 17:40 UTC (Wed) by mepr (guest, #4819) [Link] (1 responses)

What is the long term benefit of using legacy bios space? I was unaware that anybody was waiting to weep for the day when legacy bios goes out the window, presuming a suitably open replacement is made, and I presume that at some point, it will. At that point, Xen would have to be re-refactored.

Mark

VMware and Xen clash over Linux virtualization patch (InfoWorld)

Posted Aug 10, 2006 1:58 UTC (Thu) by aliguori (guest, #30636) [Link]

Using the option ROM space just provides an elegant mechanism for a guest to find the hypercall table without making assumptions about a memory hole. I doubt BIOS support will be removed from any major Operating System in the next decade...