From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34767 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ON5Fk-00063v-Ja for qemu-devel@nongnu.org; Fri, 11 Jun 2010 10:30:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ON5Fa-00063y-Lq for qemu-devel@nongnu.org; Fri, 11 Jun 2010 10:30:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15111) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ON5Fa-00063l-C7 for qemu-devel@nongnu.org; Fri, 11 Jun 2010 10:30:26 -0400 Date: Fri, 11 Jun 2010 11:30:22 -0300 From: Luiz Capitulino Message-ID: <20100611113022.27490bfe@redhat.com> In-Reply-To: References: <20100609175215.2e2071a0@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: aliguori@us.ibm.com, qemu-devel@nongnu.org On Thu, 10 Jun 2010 12:44:55 +0200 Juan Quintela wrote: > Luiz Capitulino wrote: > > On Wed, 9 Jun 2010 14:10:53 +0200 > > Juan Quintela wrote: > > > >> This is a resent with what we agreed on yesterday call. > >> Migration events would be there for 0.13 until we get proper > >> async command support. > > > > Something which is not clear to me is the set of events we'd have if migrate > > was an async command. > > > > Ie, do we really need MIGRATION_FAILED in this case? Don't we expect to get > > this information from the async response? > > > > I am not able to define simpler semantics for this events: Ok, I must be missing something here. First, let's talk about how async commands work today, better yet, how they should work in 0.14. I see two possible interfaces (off the top of my head): 1. QMP only returns the response when the command is finished, eg: C: { "execute": "migrate", "id": "foo" ... } /* nothing is returned, other commands are issued, after several hours... */ S: { "return": ... "id": "foo" } 2. QMP returns a response right away just to signal that the command has been accepted: C: { "execute": "migrate", "id": "foo" ... } S: { "return": {}, "id": "foo" ... } However, the actual response is emitted as an event: S: { "event": "ASYNC_RESPONSE", "return": ..., "id": "foo" } That's what I have in mind, that's why I'm confused about what we're trying to accomplish here. > - MIGRATION_STARTED: somebody started a migration, it is emited on > source and target, all monitors receive this event. The client has started the migration, it knows it. Why is the event needed? > - MIGRATION_ENDED: migration ended with sucess, all needed data is in > target machine. Also emitted in all monitors on source and target. > > - MIGRATION_CANCELED: in one of the source monitors somebody typed: > migrate_cancel. It is only emmited on the source monitors, target > monitors will receive a MIGRATION_FAILED event. > > - MIGRATION_FAILED (with this error). At this point we don't have > neither the QMP infraestructure for sending (with this error) nor > migration infrastructure to put there anything different than -1. Aren't all the three events above duplicating the async response? > This event is emmited on all source and target monitors. > - For 0.13: Event don't have a QError. > - For 0.14: It will gain a QError. > > About migration becoming an async command. Really it is independent > of what events we emit. If migration becomes async command, only > difference is for the monitor that emitted the command, rest of > monitors see nothing. If we want to be able to see that informantion > in the other monitors, we need the events anyways. Somewhere else in this discussion someone has said that we should assume that the client talking to the source is the same one which is going to talk to the target, in this case all the communication is done through the source qemu instance.