From owner-freebsd-arch@FreeBSD.ORG Fri Oct 19 06:39:21 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 1562B16A419 for ; Fri, 19 Oct 2007 06:39:21 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id F0CFE13C448 for ; Fri, 19 Oct 2007 06:39:20 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id DC4515B50; Thu, 18 Oct 2007 23:07:00 -0700 (PDT) To: Julian Elischer In-reply-to: Your message of "Thu, 18 Oct 2007 17:25:39 PDT." <4717F983.5060707@elischer.org> Date: Thu, 18 Oct 2007 23:07:00 -0700 From: Bakul Shah Message-Id: <20071019060700.DC4515B50@mail.bitblocks.com> 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 06:39:21 -0000 > 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). > 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.