Date: Thu, 18 Oct 2007 23:07:00 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Julian Elischer <julian@elischer.org> Cc: qpadla@gmail.com, freebsd-arch@freebsd.org Subject: Re: jail/vimage level virtualisation requirements. Message-ID: <20071019060700.DC4515B50@mail.bitblocks.com> In-Reply-To: Your message of "Thu, 18 Oct 2007 17:25:39 PDT." <4717F983.5060707@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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).
> 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?20071019060700.DC4515B50>