jail/vimage level virtualisation requirements.

[Julian Elischer]

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.