* Gary Hook (gary.h...@nimboxx.com) wrote:
> 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.
Is the guest that doesn't migrate idle or is it busily changing lots of memory?
> >>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.
No problem; note the postcopy code is still quite young, so don't
be too surprised if you hit other issues.
Dave
>
> Gary
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
