Univention Bugzilla – Bug 28283
VM Upgradepfad UCS-2.4 / UCS-3.0 / UCS-3.1
Last modified: 2012-12-12 21:09:42 CET
+++ This bug was initially created as a clone of Bug #27612 +++ Für libvirt-0.9.6, das wir in UCS-2.4 und UCS-3.0 verwenden. Dort angelegte VMs müssen nach dem Upgrade von libvirt und qemu auch noch mit UCS-3.1 funktionieren.
Bug #24702: Neben den alten PXE-ROMs aus etherboot-qemu sind jetzt auch die neuen PXE-ROMs aus ipxe-qemu verfügbar. Für die alten VMs mit pc-0.1x werden noch die alten ROMs verwendet, ansonsten die neuen. Zusätzlich wurde e1000 so gepatched, daß alte Saved-VM-States auch mit dem neuen qemu-kvm geladen werden können. Bug #27612: libvirt wurde auf 0.9.12 aktualisiert, das auch noch mit dem alten QEmu funktioniert. Bug #25181: UVMM wurde angepasst, daß auch Snapshots entfernt werden. Diese Änderung ist aber problematisch mit Xen, weil die Xen-Anbindung in libvirt die neuen Flags nicht unterstützt. UVMM fällt dann auf die alte Implementierung zurück. Bug #23445: QEmu wurde so gepatched, das für pc-0.1x VMs jetzt standardmäßig die Host-Cache-Strategie "none" verwendet wird, sofern nicht über UVMM eine andere Strategie explizit vorgegeben wird. Da sich diese Änderung nur für den Host-Teil von Laufwerken relevant ist, sind Saved-States davon unberührt. Testweise habe ich unter UCS-2.4-4 jeweils eine VM mit e100, rtl8139 und virtio installiert. Anschließend wurde ein Snapshot der laufenden VM angelegt und die VM suspendiert, und nochmal ein Snapshot der ausgeschalteten VM gemacht. ln /var/lib/libvirt/qemu/save/$VM /var/lib/libvirt/qemu/save/$VM.244 Anschließend wurde der Host auf UCS-3.0-2 aktualisiert. Die VM wurde dort gestartet und erneut Snapshots erstellt, die VM suspendiert, Snapshot erstellt und verlinkt. Anschließend wurde der Host auf UCS-3.1 aktualisiert. Dort wurden die VMs wieder resumed. Nur e1000 hatte ein Problem, das aber nach "ifdown eth0 ; ifup eth0" beseitigt war. Ich vermute hier ein Probelm mit der Link-Detection, die durch die neuere Version von qemu jetzt implementiert wird. Das Suspendieren dauert mit qemu-1.1.2 trotz cache=none immer noch ewig: Die Datei ist DIRECT und ohne D_SYNC geöffnert, aber trotzdem scheint kvm immer noch ein fdatasync() zu erzwingen: # fdinfo.py 2682 12 file: /var/lib/libvirt/images/ucs24-rtl-0.qcow2 pos: 3228434944 flags: RDWR DIRECT LARGEFILE CLOEXEC # strace -f -p 2682 [pid 6261] pwrite(12, "P\372\377\377\213\235\300\374\377\377\1\363\211\235\324\374\377\377\351\321\373\377\377\307\205\314\374\377\377\0\0\0"..., 32768, 4212424704) = 32768 [pid 6262] pwrite(12, "|\206\5\10\0\0\0\0\20\0\361\3779\1\0\0DM\5\10\4\0\0\0\21\0\17\0\362\2\0\0"..., 32768, 4212457472) = 32768 [pid 6261] fdatasync(12) = 0 [pid 6262] pwrite(12, "\200\0\0\0\340\235\0\0\200\0\0\0\340\236\0\0\200\0\0\0\340\237\0\0\200\0\0\0\340\240\0\0"..., 65536, 3768320000) = 65536 [pid 6261] fdatasync(12^C <unfinished ...> Das ganze dauert jedenfallso soviel zulange, das libvirtd nicht mehr antwortet, was in UVMMd wohl dazu führt, daß dieser dann plötzliche für einen Host die Daten nicht mehr aktualisiert: # libvirtd -l -v 2012-11-12 17:22:40.000+0000: 6733: warning : qemuDomainObjBeginJobInternal:838 : Cannot start job (modify, none) for domain ucs24-rtl; current job is (modify, none) owned by (6774, 0) 2012-11-12 17:22:40.000+0000: 6733: error : qemuDomainObjBeginJobInternal:842 : Timed out during operation: cannot acquire state change lock
Der UMC-Timeout ist Bug #24852.
Die Snapshot-Performance wird an Bug #29252 weiter verfolgt. Damit kann dieser Sammel-Bug dann zu.
Hier scheint es nach dem Update auf 3.1 ein Problem zu geben: root@utby:/home/stefan# tail /var/log/libvirt/qemu/stefan_UCS-3.0-2-30.1-Master-S4.log 0 bytes (0 B) copied, 7.586e-06 s, 0.0 kB/s 0+9771 records in 0+9771 records out 530554283 bytes (531 MB) copied, 14.4146 s, 36.8 MB/s 2012-11-16 19:28:02.156: shutting down 2012-11-16 19:00:36.423+0000: starting up LC_ALL=C PATH=/sbin:/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name stefan_UCS-3.0-2-30.1-Master-S4 -uuid 1693f2fb-4b5d-a501-8baf-55d8ebb7b643 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/stefan_UCS-3.0-2-30.1-Master-S4.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/stefan_UCS-3.0-2-30.1-Master-S4-0.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -drive file=/mnt/omar/vmwares/kvm/iso/ucs/UCS_3.0-2-amd64.iso,if=none,id=drive-ide0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:c6:30:71,bus=pci.0,addr=0x3 -device usb-tablet,id=input0 -vnc 0.0.0.0:2 -k de -vga cirrus -incoming fd:19 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 Unknown savevm section or instance 'kvmclock' 0 load of migration failed 2012-11-16 19:00:38.558+0000: shutting down root@utby:/home/stefan#
http://lists.fedoraproject.org/pipermail/virt/2011-August/002803.html
(In reply to comment #4) > ... /usr/bin/kvm ... -M pc-0.12 ... > Unknown savevm section or instance 'kvmclock' 0 In QEMU wurde das Verhalten von kvmclock geändert: Der Zustand wird in neueren Versionen nur noch dann gespeichert, wenn auch wirklich kvmclock benutzt wird. Aus Rückwärtkompatibilität ist kvmclock in pc-0.12 deaktiviert, denn das entspricht dem Zustand in QEMU, nicht aber dem in QEMU-KVM, denn dort war es standardmäßig aktiviert. Beim Laden des Zustandes wird nun eine neue Instanz ohne kvmclock angelegt. Diese probiet dann den gespeicherten Zustand zu laden, was für kvmclock scheitert, weil dieses Device eben in dieser Prozeß-Instanz nicht existiert. qemu-kvm wurde so gepatched, daß dort bei pc-0.12 und pc-0.13 kvmclock auch standardmäßig initialisiert werden. svn11108, qemu-kvm_1.1.2+dfsg-2.25.201211201102 ChangeLog: ±0 TBD: Eine Instanz von Sönke steht ach dem Wiederherstellen, allerdings ist das mit der alten Version von qemu-kvm-0.14. Riecht auch nach einem kvmclock-Problem. Da es allerdings nichts mit 1.1.2 zu tun hat, ignoriere ich dieses spezielle Problem erstmal.
Teilweise schon für Bug #24702 getestet. (Netzwerktreiber, Suspend/Resume)
Wenn ich eine auf boksel angelegt VM auf odda übernehme funktioniert das Starten und Wiederherstellen von Snapshots. Changelog OK
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".