Univention Bugzilla – Bug 22072
Snapshot nach Migration nicht mehr vorhanden
Last modified: 2011-09-14 10:56:22 CEST
Erstelle ich auf einem KVM Node einen Snapshot für eine virtuelle Instanz und migriere diese dann auf einen anderen KVM Node, ist der Snapshot verschwunden. Auf dem Ausgangs-Host ist eine Snapshot Config unter /var/lib/libvirt/qemu/snapshot vorhanden und auf Zielrechner der Migration auch nach der Migration nicht. Auch nach der Migration auf den Ausgangs-Host zurück ist der Snapshot weg.
Der fehlende Snapshot nach der ersten Migration ist wohl kein Problem, da auf den beiden Rechner /var/lib/libvirt/ nicht das gleiche Verzeichnis war, sondern jeweils ein lokales Verzeichnis. Warum aber wird der Snapshot auch nicht angezeigt, wenn ich dann wieder zurück migriere, also auf den Rechner auf dem die /var/lib/libvirt/qemu/snapshot... .xml Datei vorhanden war?
Noch ein Test. Auf beiden Rechnern das gleiche NFS Verzeichnis von einem dritten Rechner nach /var/lib/libvirt eingebunden. Nach der Migration ist der Snapshot weg. Die Lösung hier sollte über den Bug #22074 auch in der Doku erwähnt werden.
Für eine solche Instanz, die in UVMM nun keinen Snapshot mehr hat, zeigt qemu-info diesen jedoch noch an # KVM Node xen16-> qemu-img info /mnt/virt-images/ucs-para-amd64-0.qcow2 image: ucs-para-amd64-0.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 5.4G cluster_size: 65536 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 snap1 998M 2011-03-31 12:58:28 00:29:09.40 xen16-> file /var/lib/libvirt/qemu/snapshot/ucs-para-amd64/snap1.xml /var/lib/libvirt/qemu/snapshot/ucs-para-amd64/snap1.xml: ASCII text # UVMM Server xen4-> univention-virtual-machine-manager query qemu://xen16.uvmm.test/system ... 'disks': [{'device': 0, 'driver': u'qemu', 'driver_cache': '', 'driver_type': u'qcow2', 'readonly': False, 'size': None, 'source': u'/mnt/virt-images/ucs-para-amd64-0.qcow2', ... 'kernel': None, 'maxMem': 1073741824L, 'name': 'ucs-para-amd64', 'os_type': u'hvm', 'snapshots': {}, 'state': 5, 'uuid': '67053907-21db-9fc8-21ec-09cafbfbff2b', 'vcpus': 1}, ...
qemuDomainSnapshotLoad() wird nur einmalig beim Start von libvirtd in der Funktion qemudStartup() aufgerufen, d.h. libvirtd kennt nur die Snapshots, die beim Start vorhanden waren. Beim Wegmigrieren entfernt libvirtd die Snapshots aus dem Hauptspeicher, beim Zurückmigrieren wird die Struktur im Hauptspeicher dann aber nicht wieder neu aufgebaut.
libvirtd wurde jetzt so erweitert, das bei einem SIGHUP und nach dem Abschluß der Migration die Zusatzdaten zu den Snapshots neu eingelesen werden. Damit das zusammen mit der Migration funktioniert, muß neben einem Shared-Storage für die Image-Dateien auch ein Shared-Storage für das Verzeichnis /var/lib/libvirt/qemu/snapshot/ eingerichtet werden. Achtung: Nur für dieses Unterverzeichnis, nicht für /var/lib/libvirt/qemu/ oder gar /var/lib/libvirt/, da libvirtd darin Per-Host-Daten ablegt, was bei einer Migration dann zu Fehlern und Datenverlust führt! Zum Testen: 1. Instanz anlegen 2. Snapshot erstellen: virsh -c "qemu://$SOURCE.$DOMAINNAME/system" snapshot-create "$VM" /dev/stdin <<<"<domainsnapshot><name>$SNAP</name></domainsnapshot>" 3. Instanz migrieren: virsh -c "qemu://$SOURCE.$DOMAINNAME/system" migrate --persistent --live --undefinesource "$VM" "qemu://$TARGET.$DOMAINNAME/system" 4. Snapshot kontrolllieren: virsh -c "qemu://$TARGET.$DOMAINNAME/system" snapshot-list "$VM" 5. Snapshot anwenden: virsh -c "qemu://$TARGET.$DOMAINNAME/system" snapshot-revert "$VM" "$SNAP" 6. Instanz migrieren: virsh -c "qemu://$TARGET.$DOMAINNAME/system" migrate --persistent --live --undefinesource "$VM" "qemu://$SOURCE.$DOMAINNAME/system" 7. Snapshot kontrolllieren: virsh -c "qemu://$SOURCE.$DOMAINNAME/system" snapshot-list "$VM" Ggf. darauf achten, das auf beiden System die Zertifikate in /etc/libvirt/libvirtd.conf richtig eingetragen und unter /etc/pki/{CA,libvirt}/ verlinkt sind. svn9564, libvirt_0.8.7-1.92.201108151823 ChangeLog: \item \ucsName{libvirt} wurde so erweitert, das Sicherungspunkte bei der Migration einer Instanz nicht länger verloren gehen. Voraussetzung dafür ist, das zusätzlich das Verzeichnis \ucsURL{/var/lib/libvirt/qemu/snapshot/} über ein gemeinsames Share für alle Virtualisierungsrechner zugreifbar ist (\ucsBug{22072}).
Die Migration von _ausgeschalteten_ VMs mit _Snapshots_ funktioniert nicht. (Die Snapshots werden nicht erkannt)
svn9617, libvirt_0.8.7-1.94.201108311055 Das das Migrieren von Offline-VMs auf einem source.undefine() + target.define() beruht, wurde libvirtd so gepatched, daß bei einem define() dort auch nach existierenden Snapshots gesucht wird und diese mit der VM assoziiert werden. svn26499, univention-virtual-machine-manager-daemon_0.9.329-1.268.201108311107 Das Protokoll von UVMM wurde nun um die Information erweitert, ob die VM per managedSave() beendet wurde und ein save-Image (/var/lib/libvirt/qemu/save/$VM.save) existiert, oder ob die VM normal beendet wurde. Diese Information wird nun auch angezeigt (Bug #20853) und dafür benutzt, um bei Vorhandensein eines Save-Images die Migration und das Erstellen von neuen Sicherungspunkten zu unterdrücken. Das Wiederherstellen von Sicherungspunkten führt nun auch automatisch dazu, das ein vorhandenes save-Image gelöscht wird, da sich dieses auf den aktuellen Zustand bezieht und mit dem Wiederherstellen des Sicherungspunktes ungültig wird. Da der Benutzer den möglichen Datenverlust beim Wiederherstellen des Sicherungspunktes sowieso bestätigen muß, wurde hier keine _weitere_ Meldung hinzugefügt. Bug #22625: Erstellt man nach dem Löschen einer VM eine neue VM mit dem selben Namen, "erbt" diese dann auch die Snapshot-Metadaten; da sich die eigentlichen Snapshot-Daten in der alten Qcow2-Datei befinden, werden diese zwar angezeigt, aber funktionieren natürlich nicht. Das ist ein Upstream-libvirt-Bug, der erst durch umfangreiche Arbeiten im Bereich der Sicherungspunkte frühestens ab libvirt-0.9.5 behoben sein wird. Im Zuge dieser Arbeiten wird sich recht viel gerade auch im Zusammenhang mit Migration von VMs mit Snapshot ändern, so daß diese Problematik dann sowieso bei einer Umstellung auf eine neuere libvirt-Version nochmal aktuell wird. Für UCS-2.4-3 muß die 95%-Lösung genügen.
Wenn die VM "[gespeichert] & [beendet]" ist, ist keine Migration möglich. Migration funktioniert offline und online mit und ohne Sicherungspunkte, Sicherungspunkte können auch nach Migration wieder hergestellt werden.
Changelog ok
UCS 2.4-3 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".