Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Oct 2007 07:52:55 +0000
From:      Andrea Campi <andrea+freebsd_arch@webcom.it>
To:        Julian Elischer <julian@elischer.org>
Cc:        arch@freebsd.org, Ade Lovett <ade@FreeBSD.org>
Subject:   Re: kernel level virtualisation requirements.
Message-ID:  <20071016075255.GG61822@webcom.it>
In-Reply-To: <47140146.2020806@elischer.org>
References:  <470E5BFB.4050903@elischer.org> <470FD0DC.5080503@gritton.org> <20071013004539.R1002@10.0.0.1> <47107996.5090607@elischer.org> <2849CFD3-A747-4202-B2CB-759D3783C0B2@FreeBSD.org> <47140146.2020806@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 15, 2007 at 05:09:42PM -0700, Julian Elischer wrote:
> ? Para-virtualization
> ? VM does not simulate hardware
> ? Use special API that a modified guest OS must use
> ? Hypercalls trapped by the Hypervisor and serviced
>  + Xen, VMWare ESX Server
> 
> ? OS-level virtualization
> ? OS allows multiple secure virtual servers to be run
> ? Guest OS is the same as the host OS, but appears isolated
>  + apps see an isolated OS
>  + Solaris Containers, BSD Jails, Linux Vserver

To me, jails have always been a key distinguishing factor to FreeBSD,
so efforts to further enhance them are very welcome. However, I've
always wondering whether it was possible to also do some kind of
para-virtualization, maybe with limited scope.

In para-virtualization you modify the kernel source in such a way that
accesses to the hardware are instead translated into calls to the
hypervisor. This means you could simply write device drivers for a
"virtual network adapter", "virtual disk" etc. What this buys you is
that you can have a full kernel (say 6.x) running as a hypervisor, and
trimmed down kernels (say 7.x and several 6.x versions), compiled with
only the virtual device drivers, running as additional VMs.

This gives you a more complete emulation than what we can do with
jails (gives you the kernel in addition to the libc), while at the
same time keeping the memory cost low. The virtualization features in
recent CPUs keep the cost low, so this setup would be very useful for
instance in a lot of development tasks where you want to compare
behavior of the kernel over several branches.

By limiting the scope to only other FreeBSD versions you can build a
limited number of virtual "calls", keeping the complexity low. You
would get a framework that would be part of the base system, instead
of something biggish as Xen. It doesn't feel like a huge amount of
work either.

WDYT?

Bye,
	Andrea

-- 
If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071016075255.GG61822>