From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53266 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGzDX-0002D7-6M for qemu-devel@nongnu.org; Tue, 25 May 2010 14:51:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGzDV-0005SF-L8 for qemu-devel@nongnu.org; Tue, 25 May 2010 14:51:07 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:50518) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGzDV-0005S8-GB for qemu-devel@nongnu.org; Tue, 25 May 2010 14:51:05 -0400 Received: by vws6 with SMTP id 6so341825vws.4 for ; Tue, 25 May 2010 11:51:04 -0700 (PDT) Message-ID: <4BFC1C15.70603@codemonkey.ws> Date: Tue, 25 May 2010 13:51:01 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events References: <9b6575587d22a5c85ec536172810520ee3b945d5.1274796992.git.quintela@redhat.com> <20100525153116.167e5808@redhat.com> In-Reply-To: <20100525153116.167e5808@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu-devel@nongnu.org, Juan Quintela On 05/25/2010 01:31 PM, Luiz Capitulino wrote: > On Tue, 25 May 2010 16:21:03 +0200 > Juan Quintela wrote: > > >> They are emitted when migration starts, ends, has a failure or is canceled. >> >> Signed-off-by: Juan Quintela >> --- >> 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