From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ky7Xc-0007Js-35 for qemu-devel@nongnu.org; Thu, 06 Nov 2008 11:17:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ky7Xa-0007JX-GW for qemu-devel@nongnu.org; Thu, 06 Nov 2008 11:17:03 -0500 Received: from [199.232.76.173] (port=50065 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ky7Xa-0007JQ-8a for qemu-devel@nongnu.org; Thu, 06 Nov 2008 11:17:02 -0500 Received: from ey-out-1920.google.com ([74.125.78.146]:35483) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ky7Xa-0000ID-8A for qemu-devel@nongnu.org; Thu, 06 Nov 2008 11:17:02 -0500 Received: by ey-out-1920.google.com with SMTP id 4so299719eyk.4 for ; Thu, 06 Nov 2008 08:16:57 -0800 (PST) Message-ID: <49131875.9080500@codemonkey.ws> Date: Thu, 06 Nov 2008 10:16:53 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Possible bug in Qemu tcp migration References: <49130772.2040508@redhat.com> <49130DAC.8090207@codemonkey.ws> <4913121A.3060004@redhat.com> In-Reply-To: <4913121A.3060004@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Chris Lalancette wrote: > Anthony Liguori wrote: > >> Chris Lalancette wrote: >> >>> Anthony, >>> >>> If, instead, I add a 5 second sleep in between steps b. and c. on the source >>> side, then the migration completes as expected. It seems that the "migrate" >>> monitor command is actually returning before everything is complete, so killing >>> off the guest on the source side makes the destination wait around forever. >>> Unfortunately, I haven't yet had time to look at it in any detail to see what's >>> going on in the Qemu side, but I thought I would give you a heads up, and maybe >>> you have an idea of where to look. >>> >>> >> Can you try the latest SVN? Specifically, r5640. >> > > I took just that patch, applied it to my copy of KVM (KVM-78), and tried it out, > and it seems to have done it. Thanks Anthony! > Good, I honestly don't understand why it works ;-) Resuming the monitor should not allow monitor commands to execute until you get to the main loop. I looked through the readline code and that seems to confirm that, but perhaps you had sent monitor input already and it was buffered? So that it was just awaiting the opportunity to execute the command (no IO needed). Regards, Anthony Liguori