Univention Bugzilla – Bug 21501
Suspend von laufenden KVM VMs beim Herunterfahren des Hosts
Last modified: 2011-04-04 15:46:29 CEST
Derzeit werden die VMs auf einem KVM-Host nicht geschert, wenn der Host heruntergefahren wird. Dadurch kann es zu Datenverlust in den VMs kommen. Bei Xen wird das Sichern und wieder Starten von /etc/init.d/xendomains gehandhabt, bei KVM ist eine solches init-Skript nicht enthalten, wohl aber die notwendige Funktionalität. Diese wird von /etc/init.d/libvirt-guest genutzt, um eine äquivalente Funktionalität für alle von libvirt (>= 0.8.7) unterstützen Virtualisierungstypen (die "managedsave" implementieren) zur Verfügung zu stellen. Diese sollte standardmäßig für KVM so konfiguriert werden, daß VMs beim Herunterfahren suspendiert und nach einem Neustart automatisch wieder gestartet werden: UCR-Variablen und Vorlage in u-v-m-m-node-kvm
Änderungen wurden in u-v-m-m-node-kvm eingefügt. svn22432, univention-virtual-machine-manager-node_0.1.18-5.27.201102081307 ChangeLog: \item Virtuelle KVM-Instanzen werden beim Herunterfahren des Host-Systems nun gesichert und nach einem Neustart wieder gestartet (\ucsBug{21501}).
Wegen Bug #19145 stimmt die Boot-Reihenfolge nicht: # ls -1 /etc/rc2.d/S??*{libvirt,virtual}* /etc/rc2.d/S20libvirt-guests /etc/rc2.d/S20univention-virtual-machine-manager-daemon /etc/rc2.d/S20univention-virtual-machine-manager-node-common /etc/rc2.d/S20univention-virtual-machine-manager-node-kvm libvirt-0.8.7 wurde gepatched, so daß libvirt-guests nun S21 und K19 ist. svn8876,svn8877, libvirt_0.8.7-1.50.201102101512
now also fixed in Debian: libvirt (0.8.7-2) unstable; urgency=low * [bb7dbde] Add non dependency booting support for libvirt-guests
Wenn usplash aktiviert ist kann man nicht erkennen, dass gerade Images gespeichert und beendet werden. Als letztes werden winbind-Meldungen angezeigt.
Das Init-Skript libvirt-guests wurde nun so angepasst, daß die entsprechenden lsb-Funktionen und zusätzlich direkt usplash für den prozentualen Fortschritt aufgerufen werden. Zum direkten Testen am besten zusätzlich per ssh auf einen Rechner anmelden und dort folgendes ausführen: usplash -c -v usplash_write "TIMEOUT 0" /etc/init.d/libvirt-guests stop /etc/init.d/libvirt-guests start usplash_write "QUIT" svn8941, libvirt_0.8.7-1.53.201103091054 Keine Änderung am ChangeLog-Eintrag.
Im Init-Skript hatte sich noch ein fehlendes 'then' eingeschlichen, Paket wird neu gebaut. svn8987, libvirt_0.8.7-1.61.201103211204
libvirt verwendet nicht länger quilt direkt, sondern source/format=3.0 (quilt), was vom buildsystemd2 einmalig ausgepackt, gepatched und dann also source/format=1.0 wieder eingepackt wird. Dadurch funktionierte das Hinterlegen von zusätzlichen Patchen in debian/pacthes/* nicht mehr, so daß der Patch nicht verwendet wurde. Das wurde jetzt dahingehen geändert, daß der Patch direkt tools/libvirt-guests.init.sh anpasst. svn8990, libvirt_0.8.7-1.64.201103220905
"virsh domjobinfo" gibt Speichergrößen für Menschen lesbar als [KMGT]B aus, was das Skript noch nicht verarbeitet hat. Dies hat bei VMs mit 1G-RAM zur falschen Anzeige mit dem Faktor 1000 geführt. Das Skript wertet jetzt auch die Einheiten korrekt aus. Anmerkung: Beim Suspend laufen nicht alle Werte bis 100%, sondern ein Vorgang kann auch schon bei weniger (3%, 50%, ...) beendet sein. Dies liegt u.a. daran, daß der Großteil der Zeit für das Sichern des RAM benötigt wird. Ist der hintere Teil des Speichers bisher noch nicht beschrieben worden, d.h. ungenutzt, speichert KVM das nicht explizit, was viel schneller geht. Außerdem kann der Fall auftreten, daß nach 100% wieder 0% angezeigt wird, wenn der Speicher dann schon vollständig gesichert wurde, aber der KVM-Prozeß dann eben noch eine Sekunde länger braucht, um weitere Zustandsinformationen zu schreiben. Diesen Fall habe ich bisher einmal beobachtet. svn8992, libvirt_0.8.7-1.66.201103221127
Ausgabe funktioniert nun zuverlässig direkt in usplash und bei nosplash auf der Konsole. Getestet für 32bit und 64bit Hosts. Beim Herunterfahren werden laufende Instanzen supendiert und beim Boot gestartet (sofern die entsprechenden Variablen nicht angepasst werden). Changelogeintrag in Ordnung - verified
UCS 2.4-2 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".