From owner-freebsd-arch@FreeBSD.ORG Fri Jul 14 16:22:17 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC16F16A4DE; Fri, 14 Jul 2006 16:22:17 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C85643D49; Fri, 14 Jul 2006 16:22:16 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060714162205m92002sasme>; Fri, 14 Jul 2006 16:22:15 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k6EGM1jk076525; Fri, 14 Jul 2006 11:22:01 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k6EGLsgu076511; Fri, 14 Jul 2006 11:21:54 -0500 (CDT) (envelope-from brooks) Date: Fri, 14 Jul 2006 11:21:54 -0500 From: Brooks Davis To: Jeremie Le Hen Message-ID: <20060714162154.GA75657@lor.one-eyed-alien.net> References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <20060607160850.GB18940@odin.ac.hmc.edu> <20060608123125.W26068@fledge.watson.org> <20060714100333.GE3466@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <20060714100333.GE3466@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.11 Cc: Alex Lyashkov , Robert Watson , Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: [fbsd] Re: jail extensions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 16:22:18 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 14, 2006 at 12:03:33PM +0200, Jeremie Le Hen wrote: > Hi, >=20 > On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote: > > On Wed, 7 Jun 2006, Brooks Davis wrote: > >=20 > > >It's not clear to me that we want to use the same containers to contro= l=20 > > >all resouces since you might want a set of jails sharing IPC resources= or=20 > > >being allocated a slice of processor time to divide amongst them selve= s if=20 > > >we had a hierarchical scheduler. That said, using a single prison=20 > > >structure could do this if we allowed the administrator to specifiy a= =20 > > >hierarchy of prisons and not necessicairly enclose all resources in al= l=20 > > >prisons. > >=20 > > When looking at improved virtualization support for things like System = V=20 > > IPC, my opinion has generally been that we introduce virtualization as = a=20 > > primitive, and then have jail use the primitive much in the same way it= =20 > > does chroot. This leaves flexibility to use it without jail, etc, but m= eans=20 > > we have a well-understood and well-defined interaction with jail. >=20 > 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). >=20 > 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 --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEt8ShXY6L6fI4GtQRAkpSAKC1igSpM/x/luhXU0HmthTxB+HO7gCdG4uR 7wABUyF7TT8rWyjwUalNZ78= =YTF8 -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--