[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events

[Anthony Liguori]

On 06/12/2010 06:14 AM, Juan Quintela wrote:
> Anthony Liguori<address@hidden>  wrote:
>    
> > On 06/11/2010 09:30 AM, Luiz Capitulino wrote:
> >      
> > > On Thu, 10 Jun 2010 12:44:55 +0200
> > > Juan Quintela<address@hidden>   wrote:
> > >        
>    
> > I think we've more or less agreed that MIGRATION_CONNECTED is really
> > the event we want.
> >      
> This had the problem of migrating to a file/whatever.
>    

With migrating to exec, the MIGRATION_STARTED event fires as soon as you 
launch qemu which is also very unlikely to actually be when a QMP client 
is connected.  IOW, I'm fairly certain you'll never see a 
MIGRATION_STARTED event with QMP for exec migration anyway.

It's not useful information.  MIGRATION_CONNECTED is useful information 
and something we'll want to support long term.

> > Yes.  Today, we should just generate a MIGRATION_DONE event and let a
> > client poll for failure status.
> >      
> I disagree completely.  It just defeat the reason for this.
>
> MIGRATION_ENDED on destination machine: go ahead, everything is ok.
> MIGRATION_FAILED: Uh, oh, something got wrong, we are in the slow path.
>
> With MIGRATION_DONE + polling, we are delaying the "success" case just
> to avoid having a new event.  I don't buy it.
>    

This is an event that we plan on deprecating immediately.  Why introduce 
two events that are going to be immediately deprecated when we can just 
introduce one?

> I still think that we want the 4 events that I described.  My
> understanding is that libvirt people also would love to have that 4
> events.
>
> Answer here is that: you can do this workaround and this other
> workaround and you can get that information.
>
> About semantics of messages, I don't see anytime soon that migration are
> going to change from:
>
> Start migration and then end with success or failure.
>
> The only one that we could change/remove is MIGRATION_CANCEL to
> MIGRATION_FAILURE(User canceled) it.  But that is it.
>
> Why have to do a polling when none is needed?
> If you preffer to change the MIGRATION_ENDED + MIGRATION_FAILURE(error)
> to MIGRATION_ENDED(result code), and you have to check the error code, I
> can also live with that.  But that is it.
>    

We will have a MIGRATION_ENDED(result code) event for 0.14.  It'll be a 
proper async migrate command.  But we have no way to do this sanely 
because we can't generate rich errors during migrate and we can't pass 
QErrors over async events.

For 0.13, we need to focus on introducing the least disruptive change 
that addresses the fundamental requirement--allow clients to avoid a 
polling loop for determining when migration ends.  Having a single event 
with no payload is an extremely simple change.

Regards,

Anthony Liguori

> Later, Juan.
>