From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55902 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGx4D-0005Xi-IC for qemu-devel@nongnu.org; Tue, 25 May 2010 12:33:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGx4B-00070L-7f for qemu-devel@nongnu.org; Tue, 25 May 2010 12:33:21 -0400 Received: from mail-yw0-f185.google.com ([209.85.211.185]:54065) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGx4B-00070E-49 for qemu-devel@nongnu.org; Tue, 25 May 2010 12:33:19 -0400 Received: by ywh15 with SMTP id 15so2467463ywh.14 for ; Tue, 25 May 2010 09:33:18 -0700 (PDT) Message-ID: <4BFBFBCB.2070806@codemonkey.ws> Date: Tue, 25 May 2010 11:33:15 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events References: <9b6575587d22a5c85ec536172810520ee3b945d5.1274796992.git.quintela@redhat.com> <4BFBE843.5070202@codemonkey.ws> <4BFBF36D.8070208@codemonkey.ws> <20100525162549.GQ31759@redhat.com> In-Reply-To: <20100525162549.GQ31759@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, Juan Quintela On 05/25/2010 11:25 AM, Daniel P. Berrange wrote: > On Tue, May 25, 2010 at 06:04:17PM +0200, Juan Quintela wrote: > >> Anthony Liguori wrote: >> >>> On 05/25/2010 10:35 AM, Juan Quintela wrote: >>> >> >>>> problem here is that libvirt start target with -S, and waits to do the >>>> "cont" as soon as possible. As of know, only way to do it is to poll >>>> info migrate on source faster. >>>> >>>> >>> Why does it do that?? >>> >>> That sound like a terrible idea. >>> >> Becaues migration is not reliable, and they don't have a way to issue >> cont only in one of the sides :( >> >> We make migration protocol reliable, or management application have to >> decide when migration suceeded or not. >> >> This new events help then a lot. But they issue the cont really fast >> (before migration ends). I don't remember why they did that. >> > The use of '-S / cont' isn't really because of reliability. There > are several scenarios though. There's a migrate API option to leave > the guest paused upon completion, hence we need to start it with -S > to stop it auto-running upon completion. That's a strange API. Why would you want to do that? Why not just stop and then migrate? You're just wasting bandwidth doing a live migration and then leaving it stopped. This is a critical period of time for the guest and generally speaking, you don't want to involve many layers of management tooling in these decisions because the result is going to be that you break the migration downtime contract. > With some disk locking > approaches we need todo a lock transfer before allowing the dest > to continue running. QEMU is going to read the disk before the migration completes so the lock transfer is not going to work with the current implementation (it needs to read the disk to do probing). I assume this is not something that's actually been implemented. > It could be optimized to avoid the -S /cont > in cases where those two scenarios aren't relevant, but only if > we can get a separate async notification of when migration starts > and completes on the destination, so we can notify mgmt apps that > need this lifecycle event. > Migration completes == guest starts running. You'll get a notification of that but you're not getting that now because you're doing -S which I'd argue is a functional problem on the part of libvirt (you're breaking the downtime contract). I'm not sure why you would need a notification of when migration starts (since you know when you've started migration). Regards, Anthony Liguori > So in summary these lifecycle events on source + dest for start, > complete, fail, cancel are all focused on allowing libvirt to > remove its existing hacks in migration support for current QEMU. > > Regards, > Daniel >