From owner-freebsd-arch@FreeBSD.ORG Tue Oct 16 03:13:11 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB6F16A468 for ; Tue, 16 Oct 2007 03:13:11 +0000 (UTC) (envelope-from ade@lovett.com) Received: from mail.lovett.com (foo.lovett.com [67.134.38.158]) by mx1.freebsd.org (Postfix) with ESMTP id CBF9213C448 for ; Tue, 16 Oct 2007 03:13:11 +0000 (UTC) (envelope-from ade@lovett.com) Received: from inferno.canal.lovett.com ([172.16.32.23]:60165) by mail.lovett.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ihcrn-0000Yc-4C; Mon, 15 Oct 2007 20:13:11 -0700 In-Reply-To: <47140146.2020806@elischer.org> References: <470E5BFB.4050903@elischer.org> <470FD0DC.5080503@gritton.org> <20071013004539.R1002@10.0.0.1> <47107996.5090607@elischer.org> <2849CFD3-A747-4202-B2CB-759D3783C0B2@FreeBSD.org> <47140146.2020806@elischer.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3BC22076-E26A-4FB3-96D3-232546FF7F64@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Ade Lovett Date: Mon, 15 Oct 2007 20:13:09 -0700 To: Julian Elischer X-Mailer: Apple Mail (2.752.3) Sender: ade@lovett.com Cc: arch@freebsd.org Subject: Re: kernel level virtualisation requirements. 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: Tue, 16 Oct 2007 03:13:12 -0000 On Oct 15, 2007, at 17:09 , Julian Elischer wrote: > There are many levels of virtualisation. Sure, we can take that one as read :) [.. snip good description..] > The one I'm particularly interested in is the kind of which "jails" > is a member. > It's the one that requires us to make architectural changes to our > kernel the most, > but it is also the one that can be the most efficient. It does NOT > however allow > running of different OS's (other than possibly allowing one to have > a virtual system > that runs a userland we can emulate, e.g. some Linux an dearlier > versions of FreeBSD. Definitely a noble goal, and one that I am willing to dedicate my meagre knowledge to. The reason I brought up the RELENG_ concept is one that would likely address a very real cost. The physical hardware is, these days, a very small percentage, of the TCO. To take an example, let's look at package building. Now, with a few tweaks and hacks, it's possible to take a CURRENT machine (well, RELENG_7 right now at least in my case), and with a further few prayers, make RELENG_5/6 chroot's to build packages in addition. The machine itself as more than enough horsepower to do this - and cuts dramatically the amount of power and space required to do the job. However, this is not necessarily an ideal solution, since there is the fairly major unknown of differences between a "true" RELENG_5 system, and one that is RELENG_5 userland + RELENG_7 kernel. As APIs and ABIs change, so these unknowns become more fragile. jails absolutely serve a purpose, something which I also make extensive use of, albeit in testbed environments, for solid segregation of application-level services whilst running on the same hardware, but it does really require that both the master and all jails are synced up as far as kernel + userland goes, for each jail. I have no magic bullet to solve this, since I don't believe there is one, but perhaps by widening the scope a little (but still focusing on what we currently know as jails) we can, possibly, get to full virtualisation. -aDe