Univention Bugzilla – Bug 24702
etherboot-qemu rtl8139 pxe rom inkompatibel durch neuere Build-Toolchain
Last modified: 2012-12-12 21:09:56 CET
Wenn man das Paket etherboot in UCS-3.0 baut, unterscheiden sich die PXE-ROM-Dateie für die rtl8139 Netzwerkkarte von der Dateie aus UCS-2.4-2: # ls -l /usr/lib/etherboot/*.rom -rw-r--r-- 1 root root 65536 17. Mär 2011 /usr/lib/etherboot/e1000-82540em.rom -rw-r--r-- 1 root root 65536 17. Mär 2011 /usr/lib/etherboot/ne.rom -rw-r--r-- 1 root root 65536 17. Mär 2011 /usr/lib/etherboot/pcnet32.rom -rw-r--r-- 1 root root 65536 17. Mär 2011 /usr/lib/etherboot/rtl8029.rom -rw-r--r-- 1 root root 32768 17. Mär 2011 /usr/lib/etherboot/rtl8139.rom -rw-r--r-- 1 root root 65536 17. Mär 2011 /usr/lib/etherboot/virtio-net.rom $ ls -l /usr/lib/etherboot/*.rom -rw-r--r-- 1 root root 65536 25. Apr 2011 /usr/lib/etherboot/e1000-82540em.rom -rw-r--r-- 1 root root 65536 25. Apr 2011 /usr/lib/etherboot/ne.rom -rw-r--r-- 1 root root 65536 25. Apr 2011 /usr/lib/etherboot/pcnet32.rom -rw-r--r-- 1 root root 65536 25. Apr 2011 /usr/lib/etherboot/rtl8029.rom -rw-r--r-- 1 root root 65536 25. Apr 2011 /usr/lib/etherboot/rtl8139.rom -rw-r--r-- 1 root root 65536 25. Apr 2011 /usr/lib/etherboot/virtio-net.rom Das führt bei qemu(-kvm) dazu, das sich Snapshots und managed-save-Zustände nicht wiederherstellen lassen, weil zumindest die Größe der ROM-Datei mit der gespeicherten Größe im Zustand verglichen wird. Für UCS-3.0 wurde jetzt die Version aus UCS-2.4-2 1:1 herüberkopiert, so daß das Problem damit kurzfristig gelöst ist. Langfristig ist aber eine stabilere Lösung zu finden.
UCS-3.1: qemu/kvm-1.1
qemu-kvm wurde so gepatched, daß für VMs bis zu pc-0.14 weiterhin die alten PXE-Boot-ROMs aus etherboot-qemu verwendet werden. Für neuere VMs werden dann entsprechend die ROM-Images aus iPXE verwendet. Die Pfade dazu sind hart im kvm-Binary kodiert, da KVM Symlinks in /usr/share/kvm/ angelegt werden, die früher auf /usr/lib/etherboot/ und jetzt aus /usr/lib/ipxe/ verweisen. Da die Maschinen-Version in den XML-Daten von libvirt abgespeichert wird, ist diese auch Bestandteil der Snapshot-Informationen, so daß man diese auch aktualisieren kann, wenn man in den Genuß der neueren iPXE-ROMs kommen möchte. Dazu ist allerdings ein manuelles "virsh edit" notwendig; einen Button in UVMM gibt es (noch) nicht dazu. svn10927, qemu-kvm_1.1.2+dfsg-1.21.201210081508 ChangeLog: svn15158 \item \ucsName{QEMU-kvm} switched from the deprecated \ucsName{etherboot-qemu} to \ucsName{ipxe} to provide the network card ROM images. Old snapshots and suspended virtual machines still need the old ROM images. \ucsName{QEMU-kvm} has been patched to use the old \ucsName{etherboot-qemu} ROMs for \emph{pc-0.14} and older VMs (\ucsBug{24702}).
Drei virtuelle Maschinen mit 3.0 aufgesetzt old-e1000 old-rtl old-virtio Snapshot gemacht und in den managed saved Zustand geschickt. Nach dem Update auf 3.1 konnten old-rtl und old-virtio wieder gestartet werden. old-e1000 jedoch nicht. -> qemu: warning: error while loading state for instance 0x0 of device '0000:00:03.0/e1000'
(In reply to comment #3) > -> qemu: warning: error while loading state for instance 0x0 of device > '0000:00:03.0/e1000' Ursache ist, daß der gespeicherte Zustand für die PCI-Konfiguration der e1000 Netzwerkkarte inkompatibel mit der PCI-Konfiguration ist, wie sie von der neueren qemu-kvm-1.1.2-Version inzwischen angelegt wird: Im PCI_STATUS-Register hat sich das PCI_STATUS_CAP_LIST-Bit geändert, was als unveränderlich und für die PCI-Konfiguration als kritisch markiert ist. Auslösender Commit ist vermutlich <http://git.qemu.org/?p=qemu.git;a=commit;h=dd8e93799f13ef82d83c185b8e71e049452f7d40> Mit 0003-Bug-24702-e1000-pci-config.patch wird die Überprüfung der cmaks für die e1000 jetzt erstmal deaktiviert. Eine Rückmeldung von der qemu-Mailingliste habe ich bisher noch nicht erhalten. In dem Rahmen wurde auch noch mal die neuste Version qemu-kvm-1.1.2+dpsg-2 importiert, die ein Problem mit der seriellen (Text-)Console behebt. Auch wurde PIE deaktiviert, weil der gdb dafür zu alt ist (Bug #27785) svn10982,10984, qemu-kvm_1.1.2+dfsg-2.23.201210191339 ChangeLog: ±0
Ich konnte die Maschinen nun nach dem update wieder aus dem managed saved Zustand holen. Die alten Snapshots konnte ich auch wieder herstellen. Dann habe ich neue Snapshots angelegt und getestet. Klappt auch. Wenn ich nun aber die alten Snapshots wieder herstellen will, bekomme ich folgenden Fehler Fehler beim Wiederherstellen der Domäne "1a48f40a-4c3c-aacb-2645-0b5eddf5a939": revert requires force: Target device address type none does not match source pci (Das Erstellen der neuen Snapshost dauert auch sehr lang??)
(In reply to comment #5) > Dann habe ich neue Snapshots angelegt und getestet. Klappt auch. Wenn ich nun > aber die alten Snapshots wieder herstellen will, bekomme ich folgenden Fehler > > Fehler beim Wiederherstellen der Domäne "1a48f40a-4c3c-aacb-2645-0b5eddf5a939": > revert requires force: Target device address type none does not match source > pci Ursache ist hier, daß die neuere libvirt Version hier für den USB-Controller dessen PCI-Konfiguration in der XML-Datei abspeichert. Der Versuch dann einen alten Snapshot zu laden geht schief, weil dessen XML-Konfiguration den USB-Controller nicht explizit enthält. Mit einem zusätzlichen "--force" kann man den aber ohne Probleme laden. Diese Option wurde hinzugefügt, weil die Konfiguration des laufenden KVM-Prozesses mit der des zu ladenden Snapshots inkompatibel ist. Für eine Änderung muß der laufenden KVM-Prozeß beendet werden und durch einen neuen ersetzt werden. Dieser Vorgang beendet u.a. auch VNC-Verbindungen, weshalb die --force-Option angegeben werden muß. Unsere alte Version hat das stillschweigend gemacht, Upstream hat dagegen diese zusätzliche Sicherheitsstufe hinzugefügt. Hier wäre zu klären, ob wir einfach immer --force benutzen oder ob wir beim Benutzer nachfragen sollten. > (Das Erstellen der neuen Snapshost dauert auch sehr lang??) Ursache ist vermutlich die Cache-Strategie Write-Trough, die in Zusammenhang mit qcow2 eine Katastrophe ist: Bug #23445
(In reply to comment #6) > (In reply to comment #5) ... > > Fehler beim Wiederherstellen der Domäne "1a48f40a-4c3c-aacb-2645-0b5eddf5a939": > > revert requires force: Target device address type none does not match source > > pci ... > Hier wäre zu klären, ob wir einfach immer --force benutzen oder ob wir beim > Benutzer nachfragen sollten. UVMM verwendet nun --force, wenn es ohne Fehlschlägt. Damit sollte das auch noch mit der älteren libvirt-Versionen 0.8..14 funktionieren. svn36486, univention-virtual-machine-manager-daemon_2.0.11-1.399.201210192232 ChangeLog: ±0
Das erstellen von Snapshots von Instanzen dauert extrem lang und führt zu einer Fehlermeldung "Ein Fehler trat während der Bearbeitung Ihrer Anfrage auf." Die Maschine ist danach im "managed saved" Zustand.
Ich habe eine (begründete) Vermutung: (In reply to comment #8) > Das erstellen von Snapshots von Instanzen dauert extrem lang Das Problem ist hier, daß das neuere QEMU eben jetzt das Cache-Verhalten richtig implementiert und dadurch den bisherigen Standard cache=writethrough in Zusammenhang mit dem qcow2-Format unebnutzbar macht (Bug #23445): Das Aktualisieren der Referenzzähler-, Level-1- und 2-Tabelle ist nur ein Teil, der aber in QEMU soweit optimiert ist, daß hier intern für die Dauer der Ertsllung des Sicherungspunktes von writethough auf writeback umgeschaltet wird. Davor ruft allerdings do_savevm() qemu_savevm_state() auf, welches den Zustand der laufenden VM in die Qcow2-Datei sichert. Dabei wird allerdings nicht writeback benutzt, sondern writethrough, was die lange Wartezeit erklärt. Per gdb kann man sehen, daß das schreiben des VMState in Größe von 399.464.793 Byte am längsten dauert, das Aktualisieren der Referenzzählung für das Block-Device hat verglichen dazu keine Zeit benötigt. > und führt zu einer Fehlermeldung ... > Die Maschine ist danach im "managed saved" Zustand. Das ist dann nur noch ein weiteres Symptom: Da das Anlegen so lange dauert, verliert UMC irgendwann die Geduld umd gibt einen Fehler aus. Aus dem UVMMd.log sieht man nämlich, daß die Operation erfolgreich zuende ausgeführt wurde: 2012-10-22 11:51:48,976 - uvmmd.unix - INFO - [146] Request "DOMAIN_SNAPSHOT_CREATE" received 2012-10-22 12:07:31,948 - uvmmd.unix - INFO - [146] Connection closed. Dazwischen kommt dann aber genau nach 5 Minuten eine weitere Anfrage zu der VM: 2012-10-22 11:56:49,131 - uvmmd.command - DEBUG - DOMAIN_INFO qemu://master.kvm.fb/system 6b095316-54a6-c28c-b76a-a0cf7dddb832 Diese sieht die VM natürlich im pausiert-Zustand, weil die VM eben genau das ist um den Snaphot zu erstellen, was in UVMM dann so aussieht, als ob die VM im "managed save"-Zustand ist. (Bei KVM blenden wir den pausiert-Zustand aus, da wir hier managed_save haben wollen; nur bei Xen bieten wie pausieren an, weil wir da nichts besseres haben.) Unterm Strich sind hier 2 Dinge zu tun, die aber nicht mit der PXE-Problematik zu tun haben, sondern an Bug #23445 gehören: 1. Ein Skript schreiben, daß cache=none für alle existierenden VMs beim Update umschreibt (/etc/libvirt/qemu/*.xml, /var/lib/libvirt/qemu/save/*.save, /var/lib/libvirt/qemu/snapshot/*/*.xml) 2. qemu-kvm so patchen, daß auch für qemu_savevm_state() temporär cache=writeback gesetzt wird. Von daher mache ich diesesn Bug jetzt erstmal wieder zu.
VMs mit Intel/Realtek/Virtio Netzwerkkarte unter 3.0 angelegt, snapshotted, und suspendiert. Update auf 3.1. Fortführen: OK Snapshot erstellen: OK Alten Snapshot wieder herstellen: OK Neuen Snaphsot wieder herstellen: OK Von neuem Snapshot herunterfahren und wieder starten: OK Von altem Snapshot herunterfahren und wieder starten: OK 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".