Re: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events

[Daniel P. Berrange]

On Tue, May 25, 2010 at 06:04:17PM +0200, Juan Quintela wrote:
> Anthony Liguori <address@hidden> wrote:
> > On 05/25/2010 10:35 AM, Juan Quintela wrote:
> 
> >> problem here is that libvirt start target with -S, and waits to do the
> >> "cont" as soon as possible.  As of know, only way to do it is to poll
> >> info migrate on source faster.
> >>    
> >
> > Why does it do that??
> >
> > That sound like a terrible idea.
> 
> Becaues migration is not reliable, and they don't have a way to issue
> cont only in one of the sides :(
> 
> We make migration protocol reliable, or management application have to
> decide when migration suceeded or not.
> 
> This new events help then a lot.  But they issue the cont really fast
> (before migration ends).  I don't remember why they did that.

The use of '-S / cont' isn't really because of reliability. There
are several scenarios though. There's a migrate API option to leave
the guest paused upon completion, hence we need to start it with -S
to stop it auto-running upon completion. With some disk locking 
approaches we need todo a lock transfer before allowing the dest
to continue running. It could be optimized to avoid the -S /cont
in cases where those two scenarios aren't relevant, but only if
we can get a separate async notification of when migration starts
and completes on the destination, so we can notify mgmt apps that
need this lifecycle event.

So in summary these lifecycle events on source + dest for start,
complete, fail, cancel are all focused on allowing libvirt to 
remove its existing hacks in migration support for current QEMU.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|