From owner-freebsd-arch@FreeBSD.ORG Fri Oct 19 16:15:48 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 DFC0E16A419 for ; Fri, 19 Oct 2007 16:15:48 +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 C3D3B13C47E for ; Fri, 19 Oct 2007 16:15:46 +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 E8F7D5B3B; Fri, 19 Oct 2007 09:15:34 -0700 (PDT) To: Marko Zec In-reply-to: Your message of "Fri, 19 Oct 2007 11:33:48 +0200." <200710191133.49309.zec@icir.org> Date: Fri, 19 Oct 2007 09:15:34 -0700 From: Bakul Shah Message-Id: <20071019161534.E8F7D5B3B@mail.bitblocks.com> 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 16:15:49 -0000 > 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. 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.