From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60811 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHGRj-00010a-N5 for qemu-devel@nongnu.org; Wed, 26 May 2010 09:14:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHGRf-0001Uv-7q for qemu-devel@nongnu.org; Wed, 26 May 2010 09:14:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41039) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHGRe-0001Un-TC for qemu-devel@nongnu.org; Wed, 26 May 2010 09:14:51 -0400 Date: Wed, 26 May 2010 10:14:41 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events Message-ID: <20100526101441.440bf981@redhat.com> In-Reply-To: <4BFC1C15.70603@codemonkey.ws> References: <9b6575587d22a5c85ec536172810520ee3b945d5.1274796992.git.quintela@redhat.com> <20100525153116.167e5808@redhat.com> <4BFC1C15.70603@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Juan Quintela On Tue, 25 May 2010 13:51:01 -0500 Anthony Liguori wrote: > 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. 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?