[fbsd] Re: jail extensions

Brooks Davis brooks at one-eyed-alien.net
Fri Jul 14 16:22:18 UTC 2006


On Fri, Jul 14, 2006 at 12:03:33PM +0200, Jeremie Le Hen wrote:
> Hi,
> 
> On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote:
> > On Wed, 7 Jun 2006, Brooks Davis wrote:
> > 
> > >It's not clear to me that we want to use the same containers to control 
> > >all resouces since you might want a set of jails sharing IPC resources or 
> > >being allocated a slice of processor time to divide amongst them selves if 
> > >we had a hierarchical scheduler.  That said, using a single prison 
> > >structure could do this if we allowed the administrator to specifiy a 
> > >hierarchy of prisons and not necessicairly enclose all resources in all 
> > >prisons.
> > 
> > When looking at improved virtualization support for things like System V 
> > IPC, my opinion has generally been that we introduce virtualization as a 
> > primitive, and then have jail use the primitive much in the same way it 
> > does chroot. This leaves flexibility to use it without jail, etc, but means 
> > we have a well-understood and well-defined interaction with jail.
> 
> IMHO, it is worth having virtualization primitives wherever it is
> required and make jails use them.  This can be the case for the
> System V IPC as well as for the network stack (think of Marko's work).
> 
> My point is that the usability of virtual network stacks remains
> interesting outside the jail framework and should be able to be managed
> from its own userland tool (though the latter should probably not be
> able to destroy a virtual network stack associated with a jail).
> However I don't think that IPC are worth virtualizing outside a
> jail framework.

I could definitly use the ability to virtualize IPC inside a lighter
container then a jail.  I'd like to be able to tie them to jobs in a
batch system managed by Sun Grid Engine so I can constrain resources on
a per-job basis and insure the no IPC objects outlive the job.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20060714/49ee27ed/attachment.pgp


More information about the freebsd-arch mailing list