jail/vimage level virtualisation requirements.

[Marko Zec]

On Friday 19 October 2007 08:07:00 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
>     ...

Yup this sounds reasonable...

> 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).

Migratig kernel level state + processes from one physical machine to 
another would be extremely difficult to accomplish IMO, though having 
separated kernel resources could maybe help a little bit.  If I'm not 
mistaking DragnoFly folks have set this as their primary goal more than 
four years ago, don't know how far they have progressed towards live 
process migration...

Marko

> 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.
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to
> "freebsd-arch-unsubscribe at freebsd.org"