From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36902 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHfcJ-0002ro-3i for qemu-devel@nongnu.org; Thu, 27 May 2010 12:07:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHfcH-0001N5-L0 for qemu-devel@nongnu.org; Thu, 27 May 2010 12:07:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49991) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHfcH-0001Mp-DS for qemu-devel@nongnu.org; Thu, 27 May 2010 12:07:29 -0400 Date: Thu, 27 May 2010 13:07:22 -0300 From: Luiz Capitulino Message-ID: <20100527130722.3996af00@redhat.com> In-Reply-To: References: <9b6575587d22a5c85ec536172810520ee3b945d5.1274796992.git.quintela@redhat.com> <4BFBE843.5070202@codemonkey.ws> <4BFBF36D.8070208@codemonkey.ws> <20100525162549.GQ31759@redhat.com> <4BFBFBCB.2070806@codemonkey.ws> <20100526103346.GK18547@redhat.com> <4BFD361E.8070708@codemonkey.ws> <20100526151542.GU18547@redhat.com> <4BFD5283.70809@codemonkey.ws> <20100527104845.341fa9e5@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Thu, 27 May 2010 17:58:03 +0200 Juan Quintela wrote: > Luiz Capitulino wrote: > > On Wed, 26 May 2010 11:55:31 -0500 > > Anthony Liguori wrote: > > >> That's exactly how the protocol is designed. That was one of the major > >> improvements of QMP over the human monior. > > > > Yes and it already has 'id' support: > > > > { "execute": "cont", "id": "luiz" } > > {"timestamp": {"seconds": 1274966635, "microseconds": 776813}, "event": "RESUME"} > > {"return": {}, "id": "luiz"} > > > > But it doesn't detect duplicates, this is something I think it's up > > to the client to do, do you agree? > > > >> This is how the info balloon command works, BTW. > > > > I won't remember the details now, but that interface has some issues and it > > has to be reviewed. > > > >> Since there's a clear correlation between the request and the result of > >> the request, an asynchronous command is what makes the most sense. It > >> eliminates the problem of how to pass QErrors via an event which is one > >> of the problems with the current event proposal. > > > > Not exactly, this is a problem with QError not the event proposal. We'll > > have the same issue if we decide to include errno in the migrate errors and > > the problem still exists with the BLOCK_IO_ERROR event. > > > > That said, I do agree that migrate should be asynchronous. This yet another > > thing we may want to fix before 0.13. > > How difficult is that? Anthony is working on this and should have patches soon. [...] > >> Yes. And by deprecate, I really mean that -incoming just becomes > >> syntactic sugar for executing a monitor command immediately. > > > > But we can't change -incoming itself, since our command-line is supposed > > to be stable, right? > > > > Also, Juan has said that replacing that arg with a monitor command > > doesn't work, as qemu would have to be started in paused monitor for this > > to work. > > > > So, what about introducing a -incoming-monitor command, which puts qemu > > in the right state for migration, but requires a migrate_incoming command > > to actually start migration? > > this -incoming-monitor is called -S, that should have a long name of > -no-autostart > > that is what it does, and what we need for incoming migration as monitor > command. Nothing new to see here. Ok, I thought -S alone wasn't enough but if it's, let's go for it then.