jail/vimage level virtualisation requirements.

[Marko Zec]

On Friday 19 October 2007 18:15:34 Bakul Shah wrote:
> > Marko Zec <zec at 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.