From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48456 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONOXI-00031c-L3 for qemu-devel@nongnu.org; Sat, 12 Jun 2010 07:06:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONOXH-00063L-EV for qemu-devel@nongnu.org; Sat, 12 Jun 2010 07:06:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5946) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONOXH-00063E-5l for qemu-devel@nongnu.org; Sat, 12 Jun 2010 07:05:59 -0400 From: Juan Quintela In-Reply-To: <20100611113022.27490bfe@redhat.com> (Luiz Capitulino's message of "Fri, 11 Jun 2010 11:30:22 -0300") References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> Date: Sat, 12 Jun 2010 13:05:52 +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: aliguori@us.ibm.com, qemu-devel@nongnu.org Luiz Capitulino wrote: > 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. You continue forgeting the case that you have more than one monitor conected. The other monitor will not receive _ethire_ of that responses. Will not know what is happening. >> - 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? The monitor that did it knows it, nobody else knows it. At destination time, I guess you agree this is important, i.e. the management app knows that migration has started. I have been needinng this for audit, knowing when guest start/stop/migrates. And just now the only way to get that information is to "hack" qemu source code. With migration_events it will be "trivial" to know when that happens. In libvirt case. First thing that I would do if I receive a MIGRATION_START command that I didn't started: I release control of that VM, something fishy happened. At this point, it is imposible to know what happens. >> - 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? Again, no. Think that you have more than one monitor. And indeed in the case of a single monitor. We are delaying the information to the target management app. MIGRATION_ENDED on target machine: We can do whatever is needed when migration has ended. Async (or sync) answer to the source management app, it needs to receive that information + send that information to destination machine + receive information in destination machine + do whatever is needed on destination vm. Just because we refuse to give Information that we have, ready. I am not asking for something that is difficult to do in qemu, it is information that qemu knows (when migration has started/ended). And we are telling management apps that they need to guess when things happens and use polling to know it. >> 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. That is another problem, that we don't have a monitor in the destination target during migration. Later, Juan.