From owner-freebsd-arch@FreeBSD.ORG Fri Oct 19 19:07:28 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 2B2DB16A417 for ; Fri, 19 Oct 2007 19:07:28 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id A4AFD13C461 for ; Fri, 19 Oct 2007 19:07:27 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 8E5559B657; Fri, 19 Oct 2007 21:07:26 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.103] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 3DBEA9B652; Fri, 19 Oct 2007 21:07:24 +0200 (CEST) From: Marko Zec To: Bakul Shah Date: Fri, 19 Oct 2007 21:07:22 +0200 User-Agent: KMail/1.9.7 References: <20071019161534.E8F7D5B3B@mail.bitblocks.com> In-Reply-To: <20071019161534.E8F7D5B3B@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710192107.22571.zec@icir.org> Cc: 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 19:07:28 -0000 On Friday 19 October 2007 18:15:34 Bakul Shah wrote: > > Marko Zec > > > > On Friday 19 October 2007 08:07:00 Bakul Shah wrote: > > > 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). > > > > Migratig kernel level state + processes from one physical machine > > to another would be extremely difficult to accomplish IMO, though > > having separated kernel resources could maybe help a little bit. > > If I'm not mistaking DragnoFly folks have set this as their primary > > goal more than four years ago, don't know how far they have > > progressed towards live > > process migration... > > Note that I am not talking about process migration but > virtual machine migration. There's no such thing as true virtual machine environment with jails or with jail-like frameworks like vimage. I don't think it's realistic to expect to see a functional live jail migration from one machine to another in the forseable future. Cheers, Marko > Moving processes is far more > difficult since things are coupled too tightly in Unix. > Sharing the same file descriptor or mmap pages across diff. > machines is not even desirable. > > My thought was that if access to other machines (virtual or > real) is via network interfaces only, it would be relatively > easy. This would be like e.g. suspending your laptop at work > and and resuming at home. You lose things tightly coupled to > one environment when you move to another (such as open > connections to machines not accessible from the new > environment). > > Separating kernel resources is just one step. Even for > snapshotting on the same machine you'd need looser coupling > between components. If you can accomplish that then > migrating may not be that much more difficult. > > With VM migration you can do a lot of interesting things. > - You can for instance interactively set up a machine "just > right" for a certain type of user and resume it on N > different machines, one per user. Now each of these > machines can evolve differently (I think this is what > Julian was referring to by "pre-packaging a machine"). > - A new OS release can be just some machine's suspended state > + may be a script. New users can start using the machine > almost instantly. > - Obvious things such as replacing physical machines for > faster ones without "taking down" live VMs. > > Of course, none of this is new.