jail/vimage level virtualisation requirements.

[Bakul Shah]

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