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

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/26/2010 10:15 AM, Daniel P. Berrange wrote:
> On Wed, May 26, 2010 at 09:54:22AM -0500, Anthony Liguori wrote:
>    
>> On 05/26/2010 05:33 AM, Daniel P. Berrange wrote:
>>      
>>>>> I'm not sure why you would need a notification of when migration
>>>>> starts (since you know when you've started migration).
>>>>>
>>>>>            
>>>> But you don't know if the other end "knows" that it has also started.
>>>>
>>>> started is needed only in incoming part, because .... we don't have a
>>>> monitor to ask if migration has started.
>>>>
>>>>          
>>> If we ever want to get closer to allowing multiple monitors, or allowing
>>> apps to issue QMP commands directly via libvirt, then we still need the
>>> 'migration started' event on the source, because something else can
>>> have issued the 'migrate' command without the mgmt app knowing.
>>>
>>>        
>> Migration started doesn't help multiple monitors.  You need locking of
>> some sort.
>>
>> Part of the problem is the QMP migrate command is implemented as a
>> synchronous command.  It really ought to be an asynchronous command.
>> That tells you when the migration has actually completed without polling.
>>      
> Handling asynchronous commands is alot more complicated and error
> prone for client apps, than providing a asynchronous event notification
> of the lifecycle stages. If you want to also query status while waiting
> for the completion, it means you can have to deal with overlapping
> command  execute+return pairs within a single monitor connection.
> AFAICT this requires a change to QMP to require a unique ID to be
> sent with the {'execute'..} command and be sent back with the later
> corresponding {'return'...} data,  so you can actually correlate
> reliably.
>    

That's exactly how the protocol is designed.  That was one of the major 
improvements of QMP over the human monior.

This is how the info balloon command works, BTW.

Since there's a clear correlation between the request and the result of 
the request, an asynchronous command is what makes the most sense.  It 
eliminates the problem of how to pass QErrors via an event which is one 
of the problems with the current event proposal.

Events are meant for when there is no clear request that the event is 
associated with.  A VNC CONNECT event is a good example of this.

>    
>> On the destination side, we're really limited by the fact that we don't
>> do live incoming migrations.  The monitor doesn't get a chance to run at
>> all with exec: migration, for instance.
>>      
> If QEMU let you issue a monitor command for starting incoming
> migration, instead of using -incoming this wouldn't such a bad
> problem. eg you can launch QEMU in the desired config, with CPUs
> stopped, do the normal QMP handshake + whatever else is required
> then issue 'migrate_incoming URI' which blocked the caller for
> the duration, to allow completion to be detected.
>
>    
>> For tcp: and unix:, a CONNECTED event absolutely makes sense (every
>> socket server should emit a CONNECTED event).  Unfortunately, after
>> CONNECTED you lose the monitor until migration is complete.  If
>> something bad happens, you have to exit qemu so once the monitor
>> returns, migration has completed successfully.
>>
>> If we introduce live incoming migration, we'll need to rethink things.
>> I would actually suggest that we deprecate the incoming command if we do
>> that and make incoming migration a monitor command.  I would think it
>> should have the same semantics as migrate (as an asynchronous command).
>> A CONNECTED event still makes sense for tcp and unix protocols but I
>> don't think events make sense for start stop vs. an asynchronous command
>> completion.
>>      
> Do you actually mean 'deprecate -incoming arg' here ?
>    

Yes.  And by deprecate, I really mean that -incoming just becomes 
syntactic sugar for executing a monitor command immediately.

Regards,

Anthony Liguori

> Daniel
>