From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59954 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOABR-0002x0-OP for qemu-devel@nongnu.org; Mon, 14 Jun 2010 09:58:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOABQ-0000C5-7f for qemu-devel@nongnu.org; Mon, 14 Jun 2010 09:58:37 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:59618) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOABQ-0000Bd-1t for qemu-devel@nongnu.org; Mon, 14 Jun 2010 09:58:36 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o5EDumQ2010112 for ; Mon, 14 Jun 2010 07:56:48 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5EDwLJm038400 for ; Mon, 14 Jun 2010 07:58:21 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5EDwKxl028910 for ; Mon, 14 Jun 2010 07:58:20 -0600 Message-ID: <4C16357B.70308@linux.vnet.ibm.com> Date: Mon, 14 Jun 2010 08:58:19 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> <4C124A72.9000807@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, Luiz Capitulino On 06/12/2010 06:14 AM, Juan Quintela wrote: > Anthony Liguori wrote: > >> On 06/11/2010 09:30 AM, Luiz Capitulino wrote: >> >>> On Thu, 10 Jun 2010 12:44:55 +0200 >>> Juan Quintela wrote: >>> > >> I think we've more or less agreed that MIGRATION_CONNECTED is really >> the event we want. >> > This had the problem of migrating to a file/whatever. > With migrating to exec, the MIGRATION_STARTED event fires as soon as you launch qemu which is also very unlikely to actually be when a QMP client is connected. IOW, I'm fairly certain you'll never see a MIGRATION_STARTED event with QMP for exec migration anyway. It's not useful information. MIGRATION_CONNECTED is useful information and something we'll want to support long term. >> Yes. Today, we should just generate a MIGRATION_DONE event and let a >> client poll for failure status. >> > I disagree completely. It just defeat the reason for this. > > MIGRATION_ENDED on destination machine: go ahead, everything is ok. > MIGRATION_FAILED: Uh, oh, something got wrong, we are in the slow path. > > With MIGRATION_DONE + polling, we are delaying the "success" case just > to avoid having a new event. I don't buy it. > This is an event that we plan on deprecating immediately. Why introduce two events that are going to be immediately deprecated when we can just introduce one? > I still think that we want the 4 events that I described. My > understanding is that libvirt people also would love to have that 4 > events. > > Answer here is that: you can do this workaround and this other > workaround and you can get that information. > > About semantics of messages, I don't see anytime soon that migration are > going to change from: > > Start migration and then end with success or failure. > > The only one that we could change/remove is MIGRATION_CANCEL to > MIGRATION_FAILURE(User canceled) it. But that is it. > > Why have to do a polling when none is needed? > If you preffer to change the MIGRATION_ENDED + MIGRATION_FAILURE(error) > to MIGRATION_ENDED(result code), and you have to check the error code, I > can also live with that. But that is it. > We will have a MIGRATION_ENDED(result code) event for 0.14. It'll be a proper async migrate command. But we have no way to do this sanely because we can't generate rich errors during migrate and we can't pass QErrors over async events. For 0.13, we need to focus on introducing the least disruptive change that addresses the fundamental requirement--allow clients to avoid a polling loop for determining when migration ends. Having a single event with no payload is an extremely simple change. Regards, Anthony Liguori > Later, Juan. >