VMI - Progress Towards a Standard Paravirtualized API?
Posted by Fraser Campbell Sat, 18 Mar 2006 01:42:00 GMT
There has been a lot of traffic on various linux kernel mailing list of late relating to virtualization. Much of the recent traffic is the result of a proposal and large patchset from VMWare (at least from Zachary Amsden of VMWare).
Zach has been posting periodically on linux-kernel since 1996 and judging by code and feedback he certainly knows his stuff. The latest from Zach is a plethora of patches that implement what VMWare is calling VMI or Paravirtualization API Version 2.0.
You can read the linux-kernel post here for a good overview of the work.
High level goals of the API are portability, high performance, maintainability and extensibility.
In the maintainability section the following statement is made:
To reduce the maintenance burden as much as possible, while still allowing the implementation to accommodate changes, the design provides a stable ABI with semantic invariants.
This statement is sure to raise the ire of kernel developers. More on that later.
Back to Zach …
What we are hoping for, in the end, is a Linux kernel with a clean virtualization interface, that is maintainable, does not slow hypervisor exploitation of new technologies, still offers all of the same performance advantages, works for the open source community, and allows hypervisor vendors of many creeds to benefit from cross-kernel binary compatibility.
It is suggested that a VMI equipped kernel will detect whether a “VMI ROM” is available – if a VMI ROM is found the kernel will run paravirtualized otherwise it will run normally, even on bare metal. This certainly has some appeal.
The issue right now is that there is no known VMI capable hypervisor. One would suspect that there is a VMWare in the works (ESX, GSX, Server, ???) that will implement VMI features but no such product is announced at this time. Large patchsets for which there are no users will not be acceptable.
VMWare does claim to have run their VMI capable Linux kernel atop Xen 2.0 and they are apparently attempting to get VMI Linux running on Xen 3.0 as well but so far are unable to keep up with the rapid changes in Xen 3.
Even if a VMI capable VMWare product is released there will still be extreme resistance unless that product is open source. Kernel developers have always resisted creating stable interfaces for the benefit of code which is not shared.
For a good review on why binary modules continue to be resisted check out LWN’s article on binary drivers and stable interfaces. In a nutshell providing a stable ABI for drivers is bad because it gives vendors no incentives to improve Linux beyond their narrowly focused drivers and it gives users no opportunity to use hardware beyond the lifespan that a vendor decides upon. Also, freezing internal kernel interfaces limits the ability to innovate within the kernel.
Anyway, back to the patches …
For some time (outside of the VMI patch dump) Zach has been submitting small patches that are well received. Feedback on this latest huge patchset from Zach feedback has been quite positive (though not extensive).
Zach was asked “Why can’t vmware use the Xen interface instead?” and he responded:
We could. But it is our opinion that the Xen interface is unnecessarily complicated, without a clean separation between the layer of interaction with the hypervisor and the kernel proper. The interface we propose we believe is more powerful, and more conducive to performance optimizations while providing significant advantages – most specifically, a single binary image that is properly virtualizable on multiple hypervisors and capable of running on native hardware.
There was some agreement on this statement.
Some discussion has also occurred on the xen-devel list, an interesting tidbit from Ian Pratt (Xen lead) was
We’re currently looking though the new VMI patchset to see whether there’s anything worth having, in particular, if there’s anything that should be added to our patch to support what we can deduce that their hypervisor probably needs. We’ve also talking to the VirtualIron team to make sure we’re inclusive as possible.
As a side note, I find it quite interesting to note that VirtualIron was the first hypervisor to see support in SuSE Linux Enterprise Server. As of SLES 9 Service Pack 3 one can simply select kernel-vfe and have their VirtualIron aware kernel ready to roll. Xen is still not there yet and if you want to run SLES atop VMWare you are still stuck compiling drivers (vmxnet and vmmemctl) and installing vmware-tools tarballs – one would expect that the Novell / VMWare partnership would mean a simple merging of 2 drivers into SLES’s kernel along with an init script to start vmware-tools but not so.
One last note of interest is the University of Karlsruhe’s L4a project. This is focused on microkernels but it also has a techique which they call pre-virtualization (combining the best of para-virtualization and traditional virtualization). They are looking at VMI as one way of supporting their virtualization. Code is not ready for their VMI implemenation, though it is apparently close, in the meantime you could download their existing code here.
You may also want to check out VMWare’s VMI site here.
