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

[Juan Quintela]

Luiz Capitulino <address@hidden> wrote:
> On Fri, 11 Jun 2010 09:38:42 -0500
> Anthony Liguori <address@hidden> wrote:
>
>> >   1. QMP only returns the response when the command is finished, eg:
>> >
>> >      C: { "execute": "migrate", "id": "foo" ... }
>> >      /* nothing is returned, other commands are issued, after several 
>> > hours... */
>> >      S: { "return": ... "id": "foo" }
>> >    
>> 
>> This is how just about every RPC mechanism works...
>
>  Let's go for it then.
>
>> >> - MIGRATION_STARTED:  somebody started a migration, it is emited on
>> >>    source and target, all monitors receive this event.
>> >>      
>> >   The client has started the migration, it knows it. Why is the event 
>> > needed?
>> >    
>> 
>> I think we've more or less agreed that MIGRATION_CONNECTED is really the 
>> event we want.
>
>  Is it useful in the source or in the target?

Both.

>> >> - MIGRATION_ENDED: migration ended with sucess, all needed data is in
>> >>    target machine.  Also emitted in all monitors on source and target.
>> >>
>> >> - MIGRATION_CANCELED: in one of the source monitors somebody typed:
>> >>    migrate_cancel.  It is only emmited on the source monitors, target
>> >>    monitors will receive a MIGRATION_FAILED event.
>> >>
>> >> - MIGRATION_FAILED (with this error).  At this point we don't have
>> >>    neither the QMP infraestructure for sending (with this error) nor
>> >>    migration infrastructure to put there anything different than -1.
>> >>      
>> >   Aren't all the three events above duplicating the async response?
>> >    
>> 
>> Yes.  Today, we should just generate a MIGRATION_DONE event and let a 
>> client poll for failure status.
>
> [...]
>
>> MIGRATION_DONE gets deprecated for 0.14.
>
>  Yeah, this removes the need for polling in 0.13, but I was wondering if
> it's worth it. If I'm not mistaken, libvirt does the polling when working
> with the text Monitor and I believe it's not a big deal to keep it until 0.14.

It makes things slower for no good reason.

This reasoning is sneaky at least: 
- qemu didn't give interfaces to libvirt for do what libvirt wanted
- libvirt uses workarounds
- qemu tells libvirt that they are using workarounds that they shouldn't
- libvirt tells qemu why they need the new interface
- qemu tells libvirt that they could continue to use its workarounds.

I am losing something?  The whole point of live migration is that they
need to be as fast as possible.  For some scenaries (shared storage with
funny locking) libvirt needs to move from shared locks to normal locks
as far as migration ends on target.  We are telling them to do
workarounds becauese qemu don't want to tell libvirt on destination when
migration has ended.

Why can't we just tell them that migration has ended with success as
fast as possible?

I can't understand what I am missing here.  I can't believe that
libvirt(management app in general) could came with a simple request that
would make its live better.  And to make things worse, it is _trivial_
to implement, semantics are clear, has other uses, .....

Later, Juan.