[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