From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58863 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOY0k-0002uN-Kf for qemu-devel@nongnu.org; Tue, 15 Jun 2010 11:25:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOY0e-0003re-1S for qemu-devel@nongnu.org; Tue, 15 Jun 2010 11:25:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10897) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOY0d-0003rZ-Qy for qemu-devel@nongnu.org; Tue, 15 Jun 2010 11:25:04 -0400 From: Juan Quintela In-Reply-To: <20100615104047.260b7276@redhat.com> (Luiz Capitulino's message of "Tue, 15 Jun 2010 10:40:47 -0300") 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> Date: Tue, 15 Jun 2010 17:24:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Luiz Capitulino Cc: qemu-devel@nongnu.org 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. >> 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. 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. 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.