qemu loops/hangs on extending qcow2-diskspace

[warum]

system is ubuntu 11-10 with qemu-kvm 0.14.1 (standard dpkg)

while trying to install a software in a winXP-guest on a nearly empty disk within a qcow2-file, qemu stops answering console and vnc.

gdb on original binary shows, that it doesn't really hang, but seems to endless loop

recompiling the binary with debugging-symbols shows following problem:

in block/qcow2-cluster.c:777 there's a loop over an allocation-list, but instead of stopping somewhere, the "next" points to the current one.
 QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) { ... }

because I'm not firm with qemu-development, I don't know, which behaviour would be correct, but simply break this loop doesn't seem to work: a few moments later the process is again at this point (tried so by setting the register for comparison to 0)

this situation is continuosly reproducible, but it always take at least 10-15min to get there, so please, if you have suggestion which I should try and report, try to give as much suggestions as possible in one action.

[Serge Hallyn (serge-hallyn)]

Thanks for reporting this bug and doing the analysis.

Despite your pinpointing, I'm afraid I don't quite understand where you are saying the problem is. I'm sorry, please bear with me. The QLIST_FOREACH variables are (var, head, field), so we start with &s->cluster_allocs as head, assign 'old_alloc' to s->cluster_allocs.lh_first to begin, use that in the loop, and then on each iteration we set old_allocs = old_allocs->next_in_flight.le_next. What are you saying we should be using instead?

can you tell me exactly how to reproduce this, with a precise 'qemu-img create' command, precise kvm command, and how big the qcow2 image is when it hangs? Given how reproducible it is for you, I"m surprised I haven't run into it, so I imagine you must be using different options than I usually do. I'll try to reproduce with your exact options, so that I can try on the upstream qemu version to see if this has been fixed upstream.

Thanks again.

[warum (wiebittewas)]

sorry, if it was not as clear as it should be...

the assignment you describe is done until old_allocs is NULL (well the asm-test checks against zero, I've not looked at the macrodef of QLIST_FOREACH), but in this special case old_allocs points to address "foobar" *and* old_allocs->next_in_flight.le_next points to same address "foobar", too, so it will never become NULL and will endless loop...

gdb shows this:
777 QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) {
779 uint64_t end_offset = offset + nb_clusters * s->cluster_size;
780 uint64_t old_offset = old_alloc->offset;
779 uint64_t end_offset = offset + nb_clusters * s->cluster_size;
784 if (end_offset < old_offset || offset > old_end_offset) {
782 old_alloc->nb_clusters * s->cluster_size;
781 uint64_t old_end_offset = old_alloc->offset +
784 if (end_offset < old_offset || offset > old_end_offset) {
777 QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) {
(gdb) print old_alloc
$1 = (QCowL2Meta *) 0x34cb7a0
(gdb) print old_alloc->next_in_flight.le_next
$2 = (struct QCowL2Meta *) 0x34cb7a0

I've not analyzed, what is done within the loop, but there should be a point of another break-possibility.
I've only understood, that there's something done to expand the allocation of the qcow2-file, because of some needs within the guest.

because I don't know, how I created that certain disk, I've just started another VM with a newly created disk. this is done via the virt-manager-interface of libvirt. if this tool simply calls qemu-img or may make some api-calls by it's own - I don't know, but if it's as important I'll strace it.
the disk has a maximum of 32768MB with 0 pre-allocated.

qemu-img info say at the current loop (tried to install the soft again):

file format: qcow2
virtual size: 32G (34359738368 bytes)
disk size: 76M
cluster_size: 65536

if you want more output out of gdb, tell me. the VM currently hangs and now gdb waits for commands...

[warum (wiebittewas)]

sorry forgot the requested cmdline of kvm:
kvm -mem-path /VM/tmp -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name winxp -uuid 1c4f4992-9212-4b4c-a14d-25f2f3f28ed2 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=localtime -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x6 -drive file=/VM/winxp/lw-c.img,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/VM/winxp/lw-t.img,if=none,id=drive-ide0-0-1,snapshot=on,format=qcow2 -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/VM/winxp/lw-d.img,if=none,id=drive-ide0-1-1,format=qcow2 -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -drive file=/VM/winxp/lw-p.img,if=none,id=drive-scsi0-0-0,format=qcow2 -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=13,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=00:00:c1:a3:f4:45,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:3 -vga std -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

the disk, on which the soft should be installed is that one on the emulated scsi-controller

[Serge Hallyn (serge-hallyn)]

Are you able to reproduce this either with an Ubuntu guest, or on a 12.04 (Precise) host?

[warum (wiebittewas)]

sorry, currently I'm busy and there's too much time gone, that I can check the things in a quick way. I'll try it, when I'm less busy, but this will probably take some weeks...

[Serge Hallyn (serge-hallyn)]

Marking this bug invalid. If you can still reproduce it, please reply to let us know.