[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events |
Date: |
Wed, 26 May 2010 10:14:41 -0300 |
On Tue, 25 May 2010 13:51:01 -0500
Anthony Liguori <address@hidden> wrote:
> 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.
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?
Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events, Luiz Capitulino, 2010/05/25
[Qemu-devel] [PATCH 4/5] QMP: Emit migration events on incoming migration, Juan Quintela, 2010/05/25
[Qemu-devel] [PATCH 5/5] QMP: Emit migration events on outgoing migration, Juan Quintela, 2010/05/25