Hello,
I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an Debian
based system using AMD64 CPUs. During the install, the system froze (progress
bar didn't advance) and kvm was slowly eating CPU cycles on the host.
$ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r`
libvirt0 0.8.7-1.48.201102031226
linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101
qemu-kvm 0.12.4+dfsg-1~bpo50+1.3.201010011432
It was started using virsh, which generated the following command line:
/usr/bin/kvm.bin -S \
-M pc-0.12 \
-enable-kvm \
-m 768 \
-smp 1,sockets=1,cores=1,threads=1 \
-name 7-Professional_amd64 \
-uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \
-nodefaults \
-chardev
socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait
\
-mon chardev=monitor,mode=readline \
-rtc base=utc \
-boot dc \
-drive
file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2
-device
virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \
-drive
file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw
-device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
-drive
file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \
-device
virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3
\
-net tap,fd=20,vlan=0,name=hostnet0 \
-usb \
-device usb-tablet,id=input0 \
-vnc 0.0.0.0:0 \
-k de \
-vga cirrus \
-incoming exec:cat \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \
-no-kvm-irqchip
The "-no-kvm-irqchip"-Option was added, because we experienced shutdown/resume
problems with other machines, which either received no interrupts anymore or
where caught in their interrupt service routine, never being able to
acknowledge the interrupts. Adding that option solved that problem, but might
be causing other problems now.
Using gdb I was able to track down Windows hanging in the following routine,
which look like some spin-lock / semaphore aquire() implementation:
(gdb) x/20i 0xfffff8000c485a80
0xfffff8000c485a80: mov %rbx,0x8(%rsp)
0xfffff8000c485a85: push %rdi
0xfffff8000c485a86: sub $0x20,%rsp
0xfffff8000c485a8a: mov %rcx,%rdi
0xfffff8000c485a8d: xor %ebx,%ebx
0xfffff8000c485a8f: nop
0xfffff8000c485a90: inc %ebx
0xfffff8000c485a92: test %ebx,0x274834(%rip) # 0xfffff8000c6fa2cc
0xfffff8000c485a98: je 0xfffff8000c48adad
0xfffff8000c485a9e: pause
0xfffff8000c485aa0: mov (%rdi),%rcx
0xfffff8000c485aa3: test %rcx,%rcx
0xfffff8000c485aa6: jne 0xfffff8000c485a90
0xfffff8000c485aa8: lock btsq $0x0,(%rdi)
0xfffff8000c485aae: jb 0xfffff8000c485a90
0xfffff8000c485ab0: mov %ebx,%eax
0xfffff8000c485ab2: mov 0x30(%rsp),%rbx
0xfffff8000c485ab7: add $0x20,%rsp
0xfffff8000c485abb: pop %rdi
0xfffff8000c485abc: retq
(gdb) x/w 0xfffff8000c6fa2cc
0xfffff8000c6fa2cc: 0xffffffff
(gdb) x/w $rdi
0xfffffa800131f600: 0x00000001
Did someone experience similar problems or does somebody know if there was a
fix for such a problem in newer kvm- or Linux-kernel versions?
We also encountered problems with some Windows Versions when using VirtIO with
Qcow2 images, which were using backing-files for copy-on-write: they just
crashed with a blue-screen. Just changing from the CoW-qcow2 to the
master-qcow2 file "fixed" the problem, but this isn't satisfactory, since we
would like to use the CoW-functionality. Not using VirtIO also fixed the
problem, but has performance penalties.
Any help or comment is appreciated.
BYtE
Philipp
--
Philipp Hahn Open Source Software Engineer hahn@xxxxxxxxxxxxx
Univention GmbH Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99
http://www.univention.de/
** Besuchen Sie uns auf der CeBIT in Hannover **
** Auf dem Univention Stand D36 in Halle 2 **
** Vom 01. bis 05. März 2011 **
Attachment:
signature.asc
Description: This is a digitally signed message part.
