jail/vimage level virtualisation requirements.

Julian Elischer julian at elischer.org
Thu Oct 18 17:25:24 PDT 2007


Nikolay Pavlov wrote:
> On Thursday 18 October 2007 01:16:43 Matthew Dillon wrote:
>>   I think the reason you see such a huge degree of virtualized and
>>     para-virtualized environments these days is simply because service
>>     providers can no longer provide all the web services individual
>> sites need as a single common set of managed applications.  All they can
>> do, pretty much, is allow their users to install and run the application
>> set they need to run for their site.  In fact, there are several layers
>> of middle-management web site providers available today who simply lease
>> virtual machines and build a custom environment for their clients.
>> Virtualization neatly solves what would otherwise be a nightmare for
>> providers.
> 
> The most realistic explanation of virtualization concept. Thanks Matt. 
> 


OK so I'm changing the topic VERY slightly.

I don't want to discuss virtualisation that duplicates the entire kernel,
other than the single question "Should we drop support for jails and vimage
style virtualisation in favour of "Userland linux/dragonfly/freeBSD"
or Xen or {your favourite virtualmachine}.

IF we decide to keep teh jail/super-chroot/vimage support, then
what do we want to see out of it?

"run linux on it" is not one of the answers, (though 
"be able to run a Linux userland under emulation" may in fact be one of them.

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.


A second question is "what sort of interface would make sense for this?"
something like the "jail" program possibly.
However how about the possibility of a way of "pre-packaging" a machine?
or snapshotting a setup?













More information about the freebsd-arch mailing list