From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47544 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGwVk-0004gh-1g for qemu-devel@nongnu.org; Tue, 25 May 2010 11:57:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGwVi-0006ih-DC for qemu-devel@nongnu.org; Tue, 25 May 2010 11:57:43 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:44013) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGwVi-0006iW-8t for qemu-devel@nongnu.org; Tue, 25 May 2010 11:57:42 -0400 Received: by vws6 with SMTP id 6so155556vws.4 for ; Tue, 25 May 2010 08:57:41 -0700 (PDT) Message-ID: <4BFBF36D.8070208@codemonkey.ws> Date: Tue, 25 May 2010 10:57:33 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <9b6575587d22a5c85ec536172810520ee3b945d5.1274796992.git.quintela@redhat.com> <4BFBE843.5070202@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org On 05/25/2010 10:35 AM, Juan Quintela wrote: > Anthony Liguori wrote: > >> On 05/25/2010 09:21 AM, Juan Quintela wrote: >> > >>> +MIGRATION_CANCELED >>> +------------------ >>> + >>> +Emitted when migration is canceled. This is emitted in the source. >>> +Target will emit MIGRATION_FAILED (no way to differentiate a FAILED >>> +and CANCELED migration for target). >>> >>> >> But the management tool is the one that cancels so surely, it knows >> why already. >> > ok, then that one is ok. > > >> >>> +Data: None >>> + >>> +Example: >>> + >>> +{ "event": "MIGRATION_CANCELED", >>> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} } >>> + >>> +MIGRATION_ENDED >>> +--------------- >>> + >>> +Emitted when migration ends (both in source and target) >>> >>> >> A start event is going to be generated already, no? >> > problem here is that libvirt start target with -S, and waits to do the > "cont" as soon as possible. As of know, only way to do it is to poll > info migrate on source faster. > Why does it do that?? That sound like a terrible idea. >>> +Data: None >>> + >>> +Example: >>> + >>> +{ "event": "MIGRATION_ENDED", >>> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} } >>> + >>> +MIGRATION_FAILED >>> +---------------- >>> + >>> +Emitted when migration fails (both is source and target). >>> + >>> +Data: None >>> >>> >> There should be some information about why it failed, no? Preferrably >> in a QError format. >> > At this point, we have basically -1 :( > > I can add a field with an error number, but we are very bad at the > moment about moving errno's upstack. > We need a better solution for reporting errors via notifications. >> I think this makes more sense as a MIGRATION_CONNECTED event. It >> probably should carry peer information too. >> > What kind of peer information? > > We have tcp/fd/exec/unix migrations. calling it CONNECTED vs STARTED, I > don't care. But adding information? Notice that the management > application knows what it did, I can put the: > > "exec: gzip -d< /tmp/foo" > > string, but not much more that I can put here. > Basically, do we have any useful information in info migrate that we can include? Regards, Anthony Liguori > Later, Juan. >