From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41437 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHI04-0008Ly-6D for qemu-devel@nongnu.org; Wed, 26 May 2010 10:54:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHI02-0005JJ-TG for qemu-devel@nongnu.org; Wed, 26 May 2010 10:54:28 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:54119) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHI02-0005J8-Pb for qemu-devel@nongnu.org; Wed, 26 May 2010 10:54:26 -0400 Received: by gwb11 with SMTP id 11so1034558gwb.4 for ; Wed, 26 May 2010 07:54:25 -0700 (PDT) Message-ID: <4BFD361E.8070708@codemonkey.ws> Date: Wed, 26 May 2010 09:54:22 -0500 From: Anthony Liguori MIME-Version: 1.0 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> In-Reply-To: <20100526103346.GK18547@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: "Daniel P. Berrange" Cc: Luiz Capitulino , qemu-devel@nongnu.org, Juan Quintela On 05/26/2010 05:33 AM, Daniel P. Berrange wrote: >>> I'm not sure why you would need a notification of when migration >>> starts (since you know when you've started migration). >>> >> But you don't know if the other end "knows" that it has also started. >> >> started is needed only in incoming part, because .... we don't have a >> monitor to ask if migration has started. >> > If we ever want to get closer to allowing multiple monitors, or allowing > apps to issue QMP commands directly via libvirt, then we still need the > 'migration started' event on the source, because something else can > have issued the 'migrate' command without the mgmt app knowing. > Migration started doesn't help multiple monitors. You need locking of some sort. Part of the problem is the QMP migrate command is implemented as a synchronous command. It really ought to be an asynchronous command. That tells you when the migration has actually completed without polling. On the source end, I can't think of any events that would be useful. The migrate command can complete with a failure so that gives you failure notifications. On the destination side, we're really limited by the fact that we don't do live incoming migrations. The monitor doesn't get a chance to run at all with exec: migration, for instance. For tcp: and unix:, a CONNECTED event absolutely makes sense (every socket server should emit a CONNECTED event). Unfortunately, after CONNECTED you lose the monitor until migration is complete. If something bad happens, you have to exit qemu so once the monitor returns, migration has completed successfully. If we introduce live incoming migration, we'll need to rethink things. I would actually suggest that we deprecate the incoming command if we do that and make incoming migration a monitor command. I would think it should have the same semantics as migrate (as an asynchronous command). A CONNECTED event still makes sense for tcp and unix protocols but I don't think events make sense for start stop vs. an asynchronous command completion. Regards, Anthony Liguori > MIGRATED_STARTED+STOPPED really *is* needed if we're to make QMP cope > with all possible use cases. If we rely on inferring it from STOP+RESUME > events, it is going to exclude a significant set of use cases, and likely > result in this being proposed all over again in 12 months time :-( > > Regards, > Daniel >