Date: Fri, 19 Oct 2007 10:12:35 -0700 From: Julian Elischer <julian@elischer.org> To: Bakul Shah <bakul@bitblocks.com> Cc: qpadla@gmail.com, freebsd-arch@freebsd.org Subject: Re: jail/vimage level virtualisation requirements. Message-ID: <4718E583.8010501@elischer.org> In-Reply-To: <20071019060700.DC4515B50@mail.bitblocks.com> References: <20071019060700.DC4515B50@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah wrote:
>> Here are some possibilities for things..
>>
>> most of these are somewhat supported in one way or another somewhere.
>>
>> be able to specify a different root for the virtual machine.
>> be able to specify a different output for "uname".
>> be able to specify a different network address.
>> be able to specify a different routing table. (+)
>> be able to specify a completely different network universe (*)
>> be able to dedicate an interface to it
>> be able to have a separate PID space for it.
>> be able to specify a separate UID space for it
>> be able to specify a CPU maximum quota
>> be able to confine it to some set of CPUs
>> be able to have different mount tables for it
>> be able to specify a different security level for it.
>>
>> (+) without necessarily having a completely different universe. (see below).
>>
>> (*) e.g. being able to have two virtual have the machine get confused.
>>
>> A) this is not an exhaustive list
>> B) this list also may contain items we don't implement.
>
> Sounds like you are talking about something like rfork()
> except that instead of process resources you want to
> manipulate machine resources.
>
>> A second question is "what sort of interface would make sense for this?"
>> something like the "jail" program possibly.
>
> How about something like
>
> machine_rfork(int n, Resource* resources)
>
> where a Resource is one of
> cpu
> cpu quota
> device
> network interface
> disk
> pid space
> uid space
> root
> route table
> syscalls
> phys. memory quota
> ...
>
> The child starts with the resources specified. The new
> "machine" would be minimally initialized and the child would
> have to act like init(1) and do further initialization to
> bring it up all the way. A resource may be exclusive (the
> parent loses it) or shared (with some sharing policy) or
> newly created (where that makes sense).
>
> Presumably there would be a way to enumerate all the
> resources that can be used in machine_rfork().
>
> If you allow private virtual net interfaces you may also wish
> allow a way to create virtual networks. So for example mach0
> can create mach1, mach2 and mach3 and have them be on the
> same virtual ethernet. Mach{1,2,3} have no way of knowing
> they are not connected to a real network (except indirectly
> via performance measurements).
As a general comment People interested in this thread should look
at the 'vimage' work.
It does much of this already.
http://imunes.tel.fer.hr/virtnet/
>
>> However how about the possibility of a way of "pre-packaging" a machine?
>> or snapshotting a setup?
>
> Ideally snapshotting is done in a way that allows migrating a
> virtual machine to a different physical machine ("hibernate"
> to disk, and move state to a different machine and "wake up"
> from disk).
>
> Prepackaging can be done all (or almost all) in a user
> process. One easy thing would be to extend mtree to fetch
> files from somewhere to populate or update a new machine.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4718E583.8010501>