Date: Fri, 19 Oct 2007 21:07:22 +0200 From: Marko Zec <zec@icir.org> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-arch@freebsd.org Subject: Re: jail/vimage level virtualisation requirements. Message-ID: <200710192107.22571.zec@icir.org> In-Reply-To: <20071019161534.E8F7D5B3B@mail.bitblocks.com> References: <20071019161534.E8F7D5B3B@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 19 October 2007 18:15:34 Bakul Shah wrote:
> > Marko Zec <zec@icir.org>
> >
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710192107.22571.zec>