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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Tue, 25 May 2010 13:51:01 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> 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.

 Yeah, got it.

> >> +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?

 You mean we should have a sort of error specific events?