From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkE5K-0006Oe-Ml for qemu-devel@nongnu.org; Fri, 31 Oct 2014 11:27:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xjxkq-0004eb-Ef for qemu-devel@nongnu.org; Thu, 30 Oct 2014 17:59:47 -0400 Received: from mail-bn1on0143.outbound.protection.outlook.com ([157.56.110.143]:8800 helo=na01-bn1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xjxkq-0004dd-8u for qemu-devel@nongnu.org; Thu, 30 Oct 2014 17:59:40 -0400 From: Gary Hook Date: Thu, 30 Oct 2014 21:59:36 +0000 Message-ID: References: <20141030100344.GE2376@work-vm> <20141030200848.GA18853@work-vm> In-Reply-To: <20141030200848.GA18853@work-vm> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] Bug in recent postcopy patch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "qemu-devel@nongnu.org" Cc: "Dr. David Alan Gilbert" On 10/30/14, 3:08 PM, "Dr. David Alan Gilbert" wrote: >>I posted another thread asking about migration failure due to a copy >> taking too long, but got no traction. In the case where the problem >>raises >> its head we have turned tunneling on. A tiny VM (<2GB in size) migrates >> fine using the same procedure. Again, no shared storage. > >Is the guest that doesn't migrate idle or is it busily changing lots of >memory? Quite idle. Boot the VM, no need to start a workload, try to migrate. Failure. Also, very large VMs will fail to migrate (non-tunneled). This _seems_ to also be related to the amount of time required to copy everything from A to B. Again, tunneling seems to more quickly expose this issue as it increases the amount of time required to copy the qcow2 file over the network. I will add here that I=B9ve watched the qcow2 file grow, made a copy of it (on the receiving end) before it gets deleted, and been able to start a VM using the file. It would seem to be copasetic. I need to add tracing code to the emulator, in a way that doesn=B9t rely upon command line options or environment variables. I don=B9t see any such facility at this point. Specifically, I want to begin by watching what is going through the monitor (I.e. Return values from qemu-system-x86_64 and why there are complaints.) Unless you have any clear explanation as to why the emulator is throwing an error, could you suggest any areas I may want to focus my efforts? >>=20 >> >Thanks for the report. >>=20 >> Thank you for your time and ownership. > >No problem; note the postcopy code is still quite young, so don't >be too surprised if you hit other issues. Of course; it=B9s fresh out of the oven. But the migration of VMs using non-shared storage is not (tunneled or otherwise), and that=B9s really what I am focused on. Again, much appreciation. Gary