From owner-freebsd-arch@FreeBSD.ORG Fri Oct 19 17:12:15 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7592516A418 for ; Fri, 19 Oct 2007 17:12:15 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outC.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 52F6213C458 for ; Fri, 19 Oct 2007 17:12:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 19 Oct 2007 10:12:14 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 0561F126787; Fri, 19 Oct 2007 10:12:13 -0700 (PDT) Message-ID: <4718E583.8010501@elischer.org> Date: Fri, 19 Oct 2007 10:12:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Bakul Shah References: <20071019060700.DC4515B50@mail.bitblocks.com> In-Reply-To: <20071019060700.DC4515B50@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qpadla@gmail.com, freebsd-arch@freebsd.org Subject: Re: jail/vimage 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: Fri, 19 Oct 2007 17:12:15 -0000 Bakul Shah wrote: >> Here are some possibilities for things.. >> >> most of these are somewhat supported in one way or another somewhere. >> >> be able to specify a different root for the virtual machine. >> be able to specify a different output for "uname". >> be able to specify a different network address. >> be able to specify a different routing table. (+) >> be able to specify a completely different network universe (*) >> be able to dedicate an interface to it >> be able to have a separate PID space for it. >> be able to specify a separate UID space for it >> be able to specify a CPU maximum quota >> be able to confine it to some set of CPUs >> be able to have different mount tables for it >> be able to specify a different security level for it. >> >> (+) without necessarily having a completely different universe. (see below). >> >> (*) e.g. being able to have two virtual have the machine get confused. >> >> A) this is not an exhaustive list >> B) this list also may contain items we don't implement. > > Sounds like you are talking about something like rfork() > except that instead of process resources you want to > manipulate machine resources. > >> A second question is "what sort of interface would make sense for this?" >> something like the "jail" program possibly. > > How about something like > > machine_rfork(int n, Resource* resources) > > where a Resource is one of > cpu > cpu quota > device > network interface > disk > pid space > uid space > root > route table > syscalls > phys. memory quota > ... > > The child starts with the resources specified. The new > "machine" would be minimally initialized and the child would > have to act like init(1) and do further initialization to > bring it up all the way. A resource may be exclusive (the > parent loses it) or shared (with some sharing policy) or > newly created (where that makes sense). > > Presumably there would be a way to enumerate all the > resources that can be used in machine_rfork(). > > If you allow private virtual net interfaces you may also wish > allow a way to create virtual networks. So for example mach0 > can create mach1, mach2 and mach3 and have them be on the > same virtual ethernet. Mach{1,2,3} have no way of knowing > they are not connected to a real network (except indirectly > via performance measurements). As a general comment People interested in this thread should look at the 'vimage' work. It does much of this already. http://imunes.tel.fer.hr/virtnet/ > >> However how about the possibility of a way of "pre-packaging" a machine? >> or snapshotting a setup? > > Ideally snapshotting is done in a way that allows migrating a > virtual machine to a different physical machine ("hibernate" > to disk, and move state to a different machine and "wake up" > from disk). > > Prepackaging can be done all (or almost all) in a user > process. One easy thing would be to extend mtree to fetch > files from somewhere to populate or update a new machine.