Bug 28283 - VM Upgradepfad UCS-2.4 / UCS-3.0 / UCS-3.1
VM Upgradepfad UCS-2.4 / UCS-3.0 / UCS-3.1
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Virtualization - UVMM
UCS 3.0
All Linux
: P5 normal (vote)
: UCS 3.1
Assigned To: Philipp Hahn
Janek Walkenhorst
: interim-3
Depends on: 27612
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-22 19:54 CEST by Philipp Hahn
Modified: 2012-12-12 21:09 CET (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Hahn univentionstaff 2012-08-22 19:54:06 CEST
+++ 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.
Comment 1 Philipp Hahn univentionstaff 2012-11-12 18:48:18 CET
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
Comment 2 Philipp Hahn univentionstaff 2012-11-15 14:05:43 CET
Der UMC-Timeout ist Bug #24852.
Comment 3 Philipp Hahn univentionstaff 2012-11-16 08:50:21 CET
Die Snapshot-Performance wird an Bug #29252 weiter verfolgt.
Damit kann dieser Sammel-Bug dann zu.
Comment 4 Stefan Gohmann univentionstaff 2012-11-16 20:04:21 CET
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#
Comment 6 Philipp Hahn univentionstaff 2012-11-20 13:03:42 CET
(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.
Comment 7 Janek Walkenhorst univentionstaff 2012-11-21 18:01:24 CET
Teilweise schon für Bug #24702 getestet. (Netzwerktreiber, Suspend/Resume)
Comment 8 Janek Walkenhorst univentionstaff 2012-11-22 12:40:53 CET
Wenn ich eine auf boksel angelegt VM auf odda übernehme funktioniert das Starten und Wiederherstellen von Snapshots.

Changelog OK
Comment 9 Stefan Gohmann univentionstaff 2012-12-12 21:09:42 CET
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".