From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51011 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOWNx-0005Vk-DT for qemu-devel@nongnu.org; Tue, 15 Jun 2010 09:41:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOWNr-0000AL-VK for qemu-devel@nongnu.org; Tue, 15 Jun 2010 09:40:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52641) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOWNr-0000AA-Oe for qemu-devel@nongnu.org; Tue, 15 Jun 2010 09:40:55 -0400 Date: Tue, 15 Jun 2010 10:40:47 -0300 From: Luiz Capitulino Message-ID: <20100615104047.260b7276@redhat.com> In-Reply-To: References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> <4C1636BC.704@linux.vnet.ibm.com> <4C165482.6020601@linux.vnet.ibm.com> <4C167DE4.8080104@linux.vnet.ibm.com> <4C168A81.8060302@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP 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 Tue, 15 Jun 2010 12:30:57 +0200 Juan Quintela wrote: > Anthony Liguori wrote: > > On 06/14/2010 02:54 PM, Juan Quintela wrote: > >> Anthony Liguori wrote: > > >>> What makes migration important and not savevm? > >>> > >> That is the reason why I insist to have the events "both" in source and > >> destination. About how to integrate savevm on the whole picture .... > >> > >> VM_SAVE_START/VM_SAVE_END/VM_RESTORE_START/VM_RESTORE_END events? > >> > > > > If savevm is an asychronous command, then it's already there. > > > > You really want to support turning all command submissions/completions > > into events. You could do it with two events. The first would be > > COMMAND_REQUEST and would contain the request data and which monitor > > it occurred on. The second would be COMMAND_RESPONSE and would > > contain the response data and which monitor it occurred on. > > > > But honestly, I think it's a stretch to say this functionality is > > really needed. > > As already told, what I need is the migration ones. > > The imporant case is MIGRATION_ENDED on target when migration were > sucessful. This is the fast path, and it makes a difference here. I think we could avoid this one too, but as it has a clear feature for 0.13, I'm not too opposed either. > MIGRATION_STARTED on target is also quite "nice" to have. At this point > libvirt has an > > sleep(250ms): echo "cont" > > Due to a race here in incoming migration. Hm. Did you investigate that race in detail? I hope we're not using events to hide bugs. > As we only wanted one ending event, can agree on: > > MIGRATION_STARTED(both source and target) > MIGRATION_DONE(result) (both source and target) > > where result can be ok or -1 (at this point we don't have anything else > to put there). > > That moves us from 4 events to 2? I still don't see the need for MIGRATION_STARTED, it could be useful in the target but I'd like to understand the use case in more detail.