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

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/25/2010 01:31 PM, Luiz Capitulino wrote:
> On Tue, 25 May 2010 16:21:03 +0200
> Juan Quintela<quintela@redhat.com>  wrote:
>
>    
>> They are emitted when migration starts, ends, has a failure or is canceled.
>>
>> Signed-off-by: Juan Quintela<quintela@redhat.com>
>> ---
>>   QMP/qmp-events.txt |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>   monitor.c          |   12 ++++++++++++
>>   monitor.h          |    4 ++++
>>   3 files changed, 66 insertions(+), 0 deletions(-)
>>
>> diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
>> index 01ec85f..93caa4d 100644
>> --- a/QMP/qmp-events.txt
>> +++ b/QMP/qmp-events.txt
>> @@ -26,6 +26,56 @@ Example:
>>   Note: If action is "stop", a STOP event will eventually follow the
>>   BLOCK_IO_ERROR event.
>>
>> +MIGRATION_CANCELED
>> +------------------
>> +
>> +Emitted when migration is canceled.  This is emitted in the source.
>>      
>   Shouldn't this one be emitted in the destination?
>    

Destination can't distinguish a cancelled from a closed pipe.  But the 
idea is that a third party is talking to both source and destination so 
it knows if it's cancelled the migration.

>> +Target will emit MIGRATION_FAILED (no way to differentiate a FAILED
>> +and CANCELED migration for target).
>> +
>> +Data: None
>> +
>> +Example:
>> +
>> +{ "event": "MIGRATION_CANCELED",
>> +    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
>> +
>> +MIGRATION_ENDED
>> +---------------
>> +
>> +Emitted when migration ends (both in source and target)
>> +
>> +Data: None
>> +
>> +Example:
>> +
>> +{ "event": "MIGRATION_ENDED",
>> +    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
>> +
>> +MIGRATION_FAILED
>> +----------------
>> +
>> +Emitted when migration fails (both is source and target).
>> +
>> +Data: None
>> +
>> +Example:
>> +
>> +{ "event": "MIGRATION_FAILED",
>> +    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
>>      
>   What about a MIGRATION_FINISHED event, which contains a 'success'
> key which is a bool?
>
>   The only disadvantage of this is if we decide to add more information
> to the event (say, stats) then it'd get ugly. Otherwise, one event is enough.
>
>   Anyway, the counterpart of MIGRATION_FAILED is MIGRATION_SUCCEEDED.
>    

I see MIGRATION_FAILED as being very similar to block I/O error events.  
I think we'll need a very similar solution for both.  It boils down to, 
how do we raise asynchronous events when something fails?

Regards,

Anthony Liguori