Date: Fri, 19 Oct 2007 09:15:34 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Marko Zec <zec@icir.org> Cc: freebsd-arch@freebsd.org Subject: Re: jail/vimage level virtualisation requirements. Message-ID: <20071019161534.E8F7D5B3B@mail.bitblocks.com> In-Reply-To: Your message of "Fri, 19 Oct 2007 11:33:48 %2B0200." <200710191133.49309.zec@icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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?20071019161534.E8F7D5B3B>