From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33628 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOww8-0003Yq-QY for qemu-devel@nongnu.org; Wed, 16 Jun 2010 14:02:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOww7-000506-BQ for qemu-devel@nongnu.org; Wed, 16 Jun 2010 14:02:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26923) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOww7-0004zt-3l for qemu-devel@nongnu.org; Wed, 16 Jun 2010 14:02:03 -0400 Date: Wed, 16 Jun 2010 15:01:55 -0300 From: Luiz Capitulino Message-ID: <20100616150155.49acbc50@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> <20100615104047.260b7276@redhat.com> 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 17:24:59 +0200 Juan Quintela wrote: > Luiz Capitulino wrote: > > 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. > > Yes. we can call "cont" while staying in "waiting for incomming > migration" because we dont' have "waiting incoming migraiton" than > vm_start/stop understand. > > Reviewing all callers to see that I can add a new state. Will skip this one because it seems to be being discussed in a different thread. > >> 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. > > At this point, if you are doing migration with tcp, and you are putting > the wrong port on source (no path or any other error), you get no info > at all of what is happening. Shouldn't the migrate command just the return the expected error? > It is important to be sure than migration has started, i.e. something > happenend. It happens to me all the time, and users with more complex > setup will like it to know what is happening. It already happened to me too, but I feel that the event is being used as a workaround: we should return good error information instead, like this: (qemu) migrate tcp:foobar:444 migrate: Can't locate host 'foobar' (qemu) migrate tcp:doriath:1 migrate: Host 'doriath' is not listening for migration in port 1 (qemu) migrate 'exec:asd' migrate: Can't execute 'asd' In QMP the client does get an event, it's the completion response of the async command, with the error information. > As a workaround, we can try something like "info status" or ony read > only version to know that migration is not happening (because) monitor > is working (as I tell an workaround). > > Later, Juan. >