kernel level virtualisation requirements.

[Julian Elischer]

Jeff Roberson wrote:
> On Fri, 12 Oct 2007, James Gritton wrote:
> 
>> Julian Elischer wrote:
>>
>>> What I'd like to see is a bit of a 'a-la-carte' virtualisation
>>> ability.
>> ...
>>> My question to you, the reader, is:
>>> what aspects of virtualisation (the appearance of multiple instances
>>> of some resource) would you like to see in the system?
>>
>> Of course everything jail has now, and all the network bits that 
>> vimage offers.
>>
>> CPU scheduling, in particular schedule the CPU first by jail, and then
>> by processes within jail.
> 
> So the question I have is; why do all of these things instead of 
> vmware/xen/other full virtualization?  We can implement these 
> technologies.  Specifically, I could do the CPU scheduling.  However, 
> why not just fix Xen?  There may be a very good answer to this, I just 
> don't know it.

Generally, you can run several hundred (or more) virtual jail/vimage 
style machines. xen/vmware uses so much more resources that you are usually limited to
so number like 20. it is possible in a virtual networking setup to have a single process
spanning several virtual environments (for example one process with a socket in each of 
the child universes). 

It is a valid question, but there is I think a place for both types of
partitioning.
 

> 
> Thanks,
> Jeff
> 
>>
>> Filesystem quotas, without the need for each jail to have its own 
>> mount point.
>>
>> A lot of things that fall under the IPC category: UNIX domain sockets 
>> (part of
>> jail chroot I suppose), PTYs, tunnel devices, SYSV IPC, file locks.
>>
>> Swap space and resident memory limits.
>>
>>
>> The sysctl mechanism seems a good way to declare jails as having one 
>> capability
>> or the other.  This would alleviate the need to keep updating the jail
>> structure when someone has a new idea, especially handy since the single
>> structure makes it very hard to work on more than one new idea at a time.
>>
>> - Jamie
>> _______________________________________________
>> 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"
>>