Re: [Qemu-devel] Bug in recent postcopy patch

[Gary Hook <gary.hook@nimboxx.com>]

On 10/30/14, 3:08 PM, "Dr. David Alan Gilbert" <dgilbert@redhat.com> 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¹ve 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¹t rely
upon command line options or environment variables. I don¹t 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?


>> 
>> >Thanks for the report.
>> 
>> 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¹s fresh out of the oven. But the migration of VMs using
non-shared storage is not (tunneled or otherwise), and that¹s really what
I am focused on.

Again, much appreciation.

Gary