On 10/30/14, 5:03 AM, "Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote:
>* Gary Hook (gary.h...@nimboxx.com) wrote:
>> *Knock* *knock* *knock* Is this thing on?
>
>Yes - but only by luck did I notice this; it's normally better
>to reply to the thread that posted a patch and cc the authors!
Well, that depends upon the developers, I think. I was gently admonished
on another list for addressing a developer (inadvertently) directly. But I
appreciate your openness, and would not want to abuse your attention.
>> I applied the 47 pieces of the recent postcopy patch to 2.1.2 and am
>> poking around. An attempt to migrate results in a NULL pointer
>>dereference
>> in savevm.c. Here is info from gdb:
>
>I've not tried migrating with block migration; so can you
>show the command line you used on qemu and the sequence of commands
>you used to trigger the migration?
Yessir. We invoke the emulator from libvirt. While the problem we are
dealing with applies to any VM, the one I am working with is invoked
thusly (edited for readability):
qemu-system-x86_64 -enable-kvm -name 88dbaf46-4692-4935-bd9d-8d8fac7725a9 \
-S -machine pc-0.14,accel=kvm,usb=off -m 1024 -realtime mlock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid 88dbaf46-4692-4935-bd9d-8d8fac7725a9 -no-user-config -nodefaults \
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/88dbaf46-4692-4935-bd9d-8d
8fac7725a9.monitor,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime \
-no-shutdown -boot strict=on -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-drive
file=/mnt/store01/virt/88dbaf46-4692-4935-bd9d-8d8fac7725a9.qcow2,if=none,i
d=drive-virtio-disk0,format=qcow2,cache=writeback \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virt
io-disk0,bootindex=1 \
-drive if=none,id=drive-ide0-1-0,readonly=on,format=raw \
-device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 \
-netdev tap,fd=29,id=hostnet0 -device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:07:19:5e,bus=pci.0,addr=0x3 \
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 \
-vnc 127.0.0.1:0,password -device VGA,id=video0,bus=pci.0,addr=0x2 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
-msg timestamp=on
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.
>>Q: why is max_size == 0? Does this seem correct?
>
>Yes, I think that's normal for the 1st time through the loop; (see
>migration_thread
>near the start max_size is initialised to 0).
Thank you; will do.
>>
>>
>> The patches appear to have been fully applied, but it would seem that
>>the
>> savevm_block_handlers structure needs to be updated to populate this
>> field? Which implies that a new function will have to be written?
>>
>> Or, if I have missed the obvious, I would appreciate enlightenment.
>
>Simple bug on my part; the line:
>
> if (se->ops->can_postcopy(se->opaque)) {
>
>needs to become:
> if (se->ops->can_postcopy &&
> se->ops->can_postcopy(se->opaque)) {
I wondered if that were not the case. I will make that change and see what
happens.
>Thanks for the report.
Thank you for your time and ownership.
Gary
