Date: Sat, 13 Oct 2007 00:46:58 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: James Gritton <jamie@gritton.org> Cc: arch@freebsd.org, Marko Zec <zec@freebsd.org>, Julian Elischer <julian@elischer.org> Subject: Re: kernel level virtualisation requirements. Message-ID: <20071013004539.R1002@10.0.0.1> In-Reply-To: <470FD0DC.5080503@gritton.org> References: <470E5BFB.4050903@elischer.org> <470FD0DC.5080503@gritton.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Oct 2007, James Gritton wrote: > Julian Elischer wrote: > >> What I'd like to see is a bit of a 'a-la-carte' virtualisation >> ability. > ... >> My question to you, the reader, is: >> what aspects of virtualisation (the appearance of multiple instances >> of some resource) would you like to see in the system? > > Of course everything jail has now, and all the network bits that vimage > offers. > > CPU scheduling, in particular schedule the CPU first by jail, and then > by processes within jail. So the question I have is; why do all of these things instead of vmware/xen/other full virtualization? We can implement these technologies. Specifically, I could do the CPU scheduling. However, why not just fix Xen? There may be a very good answer to this, I just don't know it. Thanks, Jeff > > Filesystem quotas, without the need for each jail to have its own mount > point. > > A lot of things that fall under the IPC category: UNIX domain sockets (part > of > jail chroot I suppose), PTYs, tunnel devices, SYSV IPC, file locks. > > Swap space and resident memory limits. > > > The sysctl mechanism seems a good way to declare jails as having one > capability > or the other. This would alleviate the need to keep updating the jail > structure when someone has a new idea, especially handy since the single > structure makes it very hard to work on more than one new idea at a time. > > - Jamie > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071013004539.R1002>