kernel level virtualisation requirements.

[Miroslav Lachman]

Julian Elischer wrote:
[...]
> I'd like to be able to say..
> I want to share the filesystem, and unix domain sockets but have a 
> separate routing domain for my processes, or maybe just
> for some sockets.  But someone else may want to have
> complete separation with everything up to and including
> separate userID spaces.
> 
> 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?
> 
> Even a discussion as to how to frame this question is up for discussion.
> 
> We don't even have a taxonomy to discus the issue.
> 
> Julian

It would be nice to have something from vserver, something from zones, 
from xen, from jails etc.
 From my point of view:

CPU limits - specified as relative part of shares (container can get 
more CPU power if CPU is not 100% loaded) or set to absolute (container 
can't get more than specified CPU power, so one can use it to test 
applications on slow CPUs etc.)

Memory limits - same as CPU

Disk - it would be nice if I can set how many disk space each container 
can use. (with similar interface as disk quotas - soft+hard limits and 
space+inodes). Maybe setting of disk I/O in similar style as CPU and 
memory limits above.

UIDs - independent UIDs in containers. In relation to UIDs, one can use 
disk quotas inside containers.

Network bandwidth - same as CPU and memory

Each container can have multiple IPs, can have own routing, firewalling 
(vimage is nice project)

Hierarchical structure - container can contain another containers.
Nested containers inherit/share resources from parent container, or can 
be limited to some part of them.
For example container1 could have 5 IPs, 40% of CPU, 200MB of memory, 
50GB of disk space, container1A could have 2 IPs, 50% of CPU of its 
parent (container1), 50MB memory, 10GB disk space, container1B could 
have no IP, 10% CPU of parent, 100MB memory, no disk space limits. Other 
not specified resources and resources for container1C are shared within 
parent container.
Nested containers could be used to set some limits (CPU, memory, disk, 
bandwidth) to more than one container at a time, I could set some limits 
to container2 and doesn't matter of setting any limits/portioning to 
container2A and container2B.

host OS --- container1 --- container1A
         |              |-- container1B
         |              \-- container1C
         |
         +-- container2 --- container2A
         |              \-- container2B
         |
         \-- container3


Others as said by James Gritton.

I know my view is too complex, but it is only subject for discussion.

I am CCing freebsd-jail at freebsd.org, as it is related to Jails. 
(discussion continue on arch at freebsd.org)

Miroslav Lachman