[Xen-devel] Re: [RFC, PATCH 0/24] VMI i386 Linux virtualization interface proposal

[Sam Vilain <sam@xxxxxxxxxx>]

Zachary Amsden wrote:

>In OLS 2005, we described the work that we have been doing in VMware
>with respect a common interface for paravirtualization of Linux. We
>shared the general vision in Rik's virtualization BoF.
>[...]
>Unlike the full-virtualization techniques used in the traditional VMware
>products, paravirtualization is a technique where the operating system
>is modified to enlighten the hypervisor with timely knowledge about the
>operating system's activities. Since the hypervisor now depends on the
>kernel to tell it about common idioms etc, it does not need to write
>protect OS objects such as page and descriptor tables as a solution
>based on full-virtualization needs. This has two important effects (a)
>it shortens the critical path, since faulting is expensive on modern
>processors (b) by eliminating complex heuristics the hypervisor is
>simplified. While the former delivers performance, the latter is quite
>important too. 
>  
>

An interesting vision, especially if it merges the current VMWare / Xen
techno-social rift.

I think there will still be a place for the "complete" (eg, QEMU, or of
course your own product) and the "ultimately lightweight" (eg,
vserver/openvz/jails/containers) approaches to virtualisation, though.

While the same kernel may be able to run in these different situations,
having a "real" hardware emulator like QEMU/VMWare will allow you to
test all of those alternate code paths.  As time goes on this will no
doubt seem a more and more superfluous requirement, especially if the
actual code in those places is minimal as you suggest.

Looking the other way, there is no way that a system like this will ever
approach the performance of fork(), as vserver and related technology
does.  No doubt for certain common applications of virtualisation, such
as providing "complete" virtual servers, this will be seen as less and
less important as time goes on.  However, for other applications - such
as jailing services, or systems that make use of advantages of single
kernel virtualisation (such as shared VFS/network, visibility into other
systems' processes, etc) - the extra kernel that a virtualisation
context implies is simply unwanted.  No doubt still other users will
simply prefer the simplicity of system call level virtualisation, such
as only having one set of routing tables/iptables rules/VGs to manage, etc.

There are currently two debates on virtualisation happening here, on and
off.  We have Xen/VMI, and vserver/openvz/jails/containers.  Let's just
try not to get them confused :-).  From the perspective of the vserver
project, I consider your work orthogonal and complementary and wish you
well in the success of your gracious offering to the Linux community.

Sam.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel