Date: Mon, 15 Oct 2007 20:13:09 -0700 From: Ade Lovett <ade@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: kernel level virtualisation requirements. Message-ID: <3BC22076-E26A-4FB3-96D3-232546FF7F64@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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_<multi> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BC22076-E26A-4FB3-96D3-232546FF7F64>