Univention Bugzilla – Bug 22877
KVM Update
Last modified: 2011-12-13 15:49:24 CET
Für UCS 3.0 sollte geprüft werden, ob ein Update für KVM sinnvoll ist.
Changelog for Version 0.14.1 virtio-blk: fail unaligned requests qed: Fix consistency check on 32-bit hosts exit if -drive specified is invalid instead of ignoring the "wrong" -drive vhost: fix dirty page handling Do not delete BlockDriverState when deleting the drive vnc: tight: Fix crash after 2GB of output lan9118: Ignore write to MAC_VLAN1 register Don't allow multiwrites against a block device without underlying medium lsi53c895a: add support for ABORT messages virtio-pci: fix bus master work around on load fix applesmc REV key rbd: don't link with -lcrypto net: Add the missing option declaration of "vhostforce" lsi53c895a: Update dnad when skipping MSGOUT bytes Revert "prep: Disable second IDE channel, as long as ISA IDE emulation doesn't support same irq for both channels" isa-bus: Remove bogus IRQ sharing check virtio-net: Fix lduw_p() pointer argument of wrong size hw/sd.c: Add missing state change for SD_STATUS, SEND_NUM_WR_BLOCKS vnc: Fix fatal crash with vnc reverse mode qemu-char: Check for missing backend name
Für UCS-3.0 wurde qemu-kvm-0.15.0, vgabios-0.6c, seabios-0.6.1.2 und ipxe-1.0.0+git-2.149b50 aus Debian importiert. Ein Upgrade auf 0.15 erscheint sinnvoll, da diese Version viele Fehler in 0.14 korrigiert <http://wiki.qemu.org/ChangeLog/0.15> und für 0.14 vermutlich keine Updates mehr erhalten wird. Die Unterschiede zwischen (xen-4.2,) qemu-0.15 und qemu-kvm-0.15 sind deutlich geringer, was den längerfristigen Support vereinfacht. > 10_without-rados.patch 0001-Bug-22877-Disable-spice-and-rados.patch > 11_drop-quilt.patch Obsolete. > 12_revert-ipxe.patch Obsolete mit Umstellung von etherboot (dead upstream) auf ipxe. > 40_qemu-kvm.git-93913dfd8acbaddc8ef3716cd7b8a2830c99cb19.patch > 41_qemu-kvm.fix_qcow2_bdrv_snapshot_goto.patch > 42_qemu-kvm.git-e063eb1f4a6d42371e7d288dfdb690d5821190ed.patch > 43_qemu-kvm.git-5a8a49d7aa78b31a853e8f5d31f5b12811caeb27.patch Obsolete backports for 0.14.1 from 0.15+git ChangeLog: \item \ucsName{Qemu-kvm} is updated to version 0.15.0 (\ucsBug{23014}).
Für Qemu-kvm wurde auch noch ein Bug-Fix-Release veröffentlicht. Um mit Qemu-0.15.1 gleichzuziehen wurde das aus Debian-sid wurde 0.15.1 importiert, der Patch zum deaktivieren von SPICE und RADOS übernommen und für 3.0 gebaut. svn9867, qemu-kvm_0.15.1+dfsg-1.15.201110240954 ChangeLog: svn10480 \item \ucsName{Qemu-kvm} is updated to version 0.15.1 (\ucsBug{22877}).
Nach dem Update auf boksel kann ich einen alten Snapshot nicht wiederherstellen: stefan@boksel:~$ sudo virsh snapshot-revert stefan_Master-2.4-4-18.1 20111021-2.4-3-joined error: revert requires force: Target domain disk count 1 does not match source 2 stefan@boksel:~$ Update: Nachdem ich die Instanz beendet hatte, konnte ich den Snapshot zurückspielen: stefan@boksel:~$ vd stefan_Master-2.4-4-18.1 Domain stefan_Master-2.4-4-18.1 destroyed stefan@boksel:~$ sudo virsh snapshot-revert stefan_Master-2.4-4-18.1 20111021-2.4-3-joined stefan@boksel:~$ Dann tritt allerdings scheinbar das gleiche Problem wie in Bug #22534, die VM reagiert nicht mehr.
Dabei fällt mir auf, dass wir auf boksel bereits den Downgrade auf die alte Kernel Version und die alte qemu-Version gemacht haben: hi qemu-kvm 0.14.1+dfsg-4.12.20110805 Full virtualization on x86 hardware root@boksel:/home/stefan# uname -a Linux boksel 2.6.32-ucs48-amd64 #1 SMP Tue Sep 6 01:52:57 UTC 2011 x86_64 GNU/Linux root@boksel:/home/stefan#
Hier kommen einige Änderungen zusammen: 1. Statt etherboot wird iPXE verwendet. Dabei unterscheidet sich die ROM-Größen, was zum Abbruch des Ladens führt: ls -l /usr/lib/etherboot/rtl8139.rom /usr/lib/ipxe/rtl8139.rom -rw-r--r-- 1 root root 32768 17. Mär 2011 /usr/lib/etherboot/rtl8139.rom -rw-r--r-- 1 root root 63488 7. Okt 15:06 /usr/lib/ipxe/rtl8139.rom 2. libvirt fügt bei der Netzwerkkarte und Baloon-Device ein zusätzliches "multifunction=on" ein, was zu einer inkompatiblen Änderung im PCI-Config-Header führt. Vermutlich hatten hier frühere Qemu-Versionen einen Bug, der in neueren Versionen korrigiert wurden. Mit einem expliziten "multifunction='off'" in den /etc/libvirt/qemu/$VM.xml und /var/lib/libvirt/qemu/snapshot/$VM/$SNAP.xml und /var/lib/libvirt/qemu/save/$VM.save Dateien funktioniert dann auch wieder ein Restore.
Für UCS-3.0 wurde nach den Problemen mit dem Wiederherstellen von Snapshots und ManagedSave wieder die alte Version aus UCS-2.4-3 übernommen. Eine neuere Version wird vermutlich dann mit 3.x geliefert. Lediglich die Build-Abhängigkeiten wurden an Squeeze / UCS-3.0 angepasst, so das nur nach RADOS deaktiviert wird. svn9920, qemu_0.14.1+dfsg-3.29.201111160955 svn9922, qemu-kvm_0.14.1+dfsg-4.16.201111160958 ChangeLog: wurde entfernt (svn10900)
Ich habe auf einem Testsystem (10.201.0.11) drei Instanzen angelegt und mit UCS 2.4-4 Snapshots dafür erstellt: - UCS 2.4 - Windows XP paravirtualisiert - Windows XP vollvirtualisiert Nach dem Update konnte ich die UCS Instanz problemlos auf einen alten Snapshot zurücksetzen, die beiden Windows Systeme leider nicht.
Der KVM-Prozeß hängt: (gdb) thread apply all bt Thread 2 (Thread 0x7fe9bcd89700 (LWP 16607)): #0 0x00007fe9c5ad716c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000043c60a in qemu_cond_wait (_env=0x13e0ec0) at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/qemu-kvm.c:1107 #2 ap_main_loop (_env=0x13e0ec0) at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/qemu-kvm.c:1460 #3 0x00007fe9c5ad28ba in start_thread () from /lib/libpthread.so.0 #4 0x00007fe9c2cb002d in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7fe9c62ea760 (LWP 16601)): #0 0x00007fe9c5ad716c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0000000000438b1f in qemu_cond_wait (env=<value optimized out>, func=<value optimized out>, data=<value optimized out>) at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/qemu-kvm.c:1107 #2 on_vcpu (env=<value optimized out>, func=<value optimized out>, data=<value optimized out>) at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/qemu-kvm.c:1161 #3 0x000000000057a275 in cpu_synchronize_state (env=0x13e0ec0) at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/kvm.h:183 #4 get_pcr_cpu (env=0x13e0ec0) at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/kvm-tpr-opt.c:213 #5 kvm_tpr_enable_vapic (env=0x13e0ec0) at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/kvm-tpr-opt.c:224 #6 0x00000000004370ae in kvm_arch_load_regs (env=0x13e0ec0, level=3) at ../qemu-kvm-x86.c:605 #7 0x0000000000438fe2 in kvm_cpu_synchronize_post_init (env=0x96de44) at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/qemu-kvm.c:1190 #8 0x000000000040ce58 in cpu_synchronize_post_init () at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/kvm.h:197 #9 cpu_synchronize_all_post_init () at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/cpus.c:98 #10 0x00000000004a5087 in qemu_loadvm_state (f=0x167fa10) at savevm.c:1826 #11 0x00000000004a5281 in load_vmstate (name=<value optimized out>) at savevm.c:2071 #12 0x000000000041bcbc in main (argc=52, argv=<value optimized out>, envp=<value optimized out>) at /var/build/temp/tmp.OM5Fs7p22e/pbuilder/qemu-kvm-0.14.1+dfsg/vl.c:3187
Problem ist hier, das durch kvm_tpr_enable_vapic() während der load_vmstate()-Initialisierung indirekt on_vcpu() aufgerufen wird, was explizit auf den VCPU-Thread wartet. Dieser existiert dann zwar bereits schon, wartet aber seinerseit darauf, das qemu sich vollständig initialisiert hat. Das wird von Thread 1 aber erst nach vollständiger Abarbeitung von load_vmstate() in kvm_main_loop() gemacht. Das ist ein Bug in qemu-0.14.1, der in qemu-0.15 nicht mehr auftritt, weil dort die Event-Loop von KVM wieder mit der ursprünglichen Qemu-Event-Loop verschmolzen wurde und große Code-Änderungen erfahren hat. Deswegen wird hier nur der Aufruf von on_vcpu() unterdrück, weil die VCPU sowieso beim loslaufen ihren Status aktualisiert. svn9951, qemu-kvm_0.14.1+dfsg-4.17.201111291810 ChangeLog: ±0
Jetzt funktioniert es wie gewünscht. Nach dem Update können die alten Snapshots wiederhergestellt werden.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"