From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkDkG-0002FG-Qf for qemu-devel@nongnu.org; Fri, 31 Oct 2014 11:04:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XkAwd-0001NL-Be for qemu-devel@nongnu.org; Fri, 31 Oct 2014 08:04:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkAwd-0001MX-3P for qemu-devel@nongnu.org; Fri, 31 Oct 2014 08:04:43 -0400 Date: Fri, 31 Oct 2014 12:04:34 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141031120433.GC3599@work-vm> References: <20141030100344.GE2376@work-vm> <20141030200848.GA18853@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Subject: Re: [Qemu-devel] Bug in recent postcopy patch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gary Hook Cc: "qemu-devel@nongnu.org" * Gary Hook (gary.hook@nimboxx.com) wrote: >=20 >=20 > On 10/30/14, 3:08 PM, "Dr. David Alan Gilbert" wrot= e: >=20 > >>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? >=20 > Quite idle. Boot the VM, no need to start a workload, try to migrate. > Failure. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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? No I don't, but there again I've not done any block stuff, and it sounds li= ke your problem is mostly related to moving the image file (which I thought libvirt preferred to do using NBD underneath now, but again, I'm not a block guy). > >> >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. >=20 > 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 wh= at > I am focused on. >=20 > Again, much appreciation. Dave > Gary >=20 -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK