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

[Anthony Liguori]

On 05/25/2010 01:31 PM, Luiz Capitulino wrote:
> On Tue, 25 May 2010 16:21:03 +0200
> Juan Quintela<address@hidden>  wrote:
>
>    
> > They are emitted when migration starts, ends, has a failure or is canceled.
> >
> > Signed-off-by: Juan Quintela<address@hidden>
> > ---
> >   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