From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37084 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONOlr-0002Bc-Rq for qemu-devel@nongnu.org; Sat, 12 Jun 2010 07:21:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONOlq-0008NC-BQ for qemu-devel@nongnu.org; Sat, 12 Jun 2010 07:21:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1025) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONOlq-0008N5-3I for qemu-devel@nongnu.org; Sat, 12 Jun 2010 07:21:02 -0400 From: Juan Quintela In-Reply-To: <20100611134228.07a32173@redhat.com> (Luiz Capitulino's message of "Fri, 11 Jun 2010 13:42:28 -0300") References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> <4C124A72.9000807@codemonkey.ws> <20100611134228.07a32173@redhat.com> Date: Sat, 12 Jun 2010 13:20:54 +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 Fri, 11 Jun 2010 09:38:42 -0500 > Anthony Liguori wrote: > >> > 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" } >> > >> >> This is how just about every RPC mechanism works... > > Let's go for it then. > >> >> - 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? >> > >> >> I think we've more or less agreed that MIGRATION_CONNECTED is really the >> event we want. > > Is it useful in the source or in the target? Both. >> >> - 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? >> > >> >> Yes. Today, we should just generate a MIGRATION_DONE event and let a >> client poll for failure status. > > [...] > >> MIGRATION_DONE gets deprecated for 0.14. > > Yeah, this removes the need for polling in 0.13, but I was wondering if > it's worth it. If I'm not mistaken, libvirt does the polling when working > with the text Monitor and I believe it's not a big deal to keep it until 0.14. It makes things slower for no good reason. This reasoning is sneaky at least: - qemu didn't give interfaces to libvirt for do what libvirt wanted - libvirt uses workarounds - qemu tells libvirt that they are using workarounds that they shouldn't - libvirt tells qemu why they need the new interface - qemu tells libvirt that they could continue to use its workarounds. I am losing something? The whole point of live migration is that they need to be as fast as possible. For some scenaries (shared storage with funny locking) libvirt needs to move from shared locks to normal locks as far as migration ends on target. We are telling them to do workarounds becauese qemu don't want to tell libvirt on destination when migration has ended. Why can't we just tell them that migration has ended with success as fast as possible? I can't understand what I am missing here. I can't believe that libvirt(management app in general) could came with a simple request that would make its live better. And to make things worse, it is _trivial_ to implement, semantics are clear, has other uses, ..... Later, Juan.