Univention Bugzilla – Bug 21636
Keine Modifikationen wenn Snapshots aktiv sind
Last modified: 2011-04-04 15:46:31 CEST
Wenn Snapshots aktiv sind, dann ist es nicht möglich Einstellungen zu ändern, beispielsweise kann dann nicht die CD geändert werden. Es sollte vielmehr so sein, dass auch die Konfiguration im Snapshot gespeichert wird und wenn der Snapshot wiederhergestellt wird, dann sollte auch die Konfiguration wiederhergestellt werden.
Das sollte nochmal geprüft werden.
Ich habe jetzt einen Snapshot erstellt. Danach habe ich per virsh die Konfiguration geändert, Speicher von 512 auf 1024 erhöht. Das Zurückspielen des Snapshots ist anschließend fehlgeschlagen: 2011-03-03 21:31:34,229 - uvmmd.unix - WARNING - [16] Error doing command "DOMAIN_SNAPSHOT_REVERT": Error reverting "9af909ab-aa94-fa38-5027-d64709cafe16" to snapshot: operation failed: Error -22 while loading VM state Nachdem ich den Arbeitsspeicher wieder auf 512 gesetzt hatte, konnte ich wieder auf den Snapshot zurück. Ich denke wir müssen bei einem Snapshot auch immer die Konfiguration speichern. Wenn es gar nicht anders geht, dann sollten wir die Daten ins LDAP schreiben.
Um es ggf. mal an einer passende Analogie zu erklären: Das Ändern von den VM-Einstellen entspricht dem Ändern der Hardware einer physikalischen Maschine: Wenn man seine Betriebssystem per Suspend-to-Disk herunterfährt, anschließend der Rechner aufschraubt und RAM ausbaut/hinzufügt, die CPU austauscht oder weitere hinzusteckt, die Anschlüsse der Festplatten-Laufwerke vertauscht oder neue hinzufügt oder alte entfernt, und dann den Rechner wieder startet, wird vermutlich auch dann feststellen, daß das S2D nicht mehr wiederhergestellt werden kann. Aus diesem Grund haben wir das Ändern im UVMM deaktiviert, sobald Snapshots vorhanden sind. Wenn ein Benutzer dann wider unseres besseren Wissens hergeht, und dir Konfiguration direkt per virsh ändern, hat sich damit ein dickes Loch ins Knie geschossen. Mir ist klar, daß VMWare das kann (es speichert die Einstellungen zu Zeitpunkt des Snapshots in der Datei *-Snapshot1.vmsn), aber libvirt macht es (derzeit) eben anders. Ich werde das mal auf der ML ansprechen.
Mir war doch so, als ob ich die Frage auf der ML schon mal gestellt hätte: <http://www.redhat.com/archives/libvir-list/2010-December/msg00331.html> Aber doppelt hält ja bekanntlich besser: http://www.redhat.com/archives/libvir-list/2011-March/msg00154.html
Wie gerade besprochen, dann sollten wir die Funktionalität in libvirt integrieren.
*** Bug 21774 has been marked as a duplicate of this bug. ***
libvirt wurde jetzt so gepatched, daß bei Qemu-Instanzen die komplette XML-Domain-Beschreibung innerhalb der Snapshot-Datei unter /var/lib/libvirt/qemu/snapshot/$VM/$SNAPSHOT.xml abgespeichert wird. Beim Wiederherstellen eines Snapshots wird der alte KVM-Prozeß derzeit immer beendet und ein neuer KVM-Prozeß mit den gespeicherten Einstellungen gestartet. Dadurch ist es jetzt leider das Umschalten zwischen nicht-umkonfigurierten VMs nicht mehr ganz so schnell. Dafür müsste jede Einstellung gesondert darauf untersucht werden, was loadvm/savevm kaputt macht und welche geändert werden können. Anpassungen am UMC rückgängig machen, so daß Snapshots wieder veränderbar sind, hat Andreas gemacht. Zum Testen: 1. Sind alte Snapshots noch ladbar (nur /domainsnapshot/domain/uuid statt vollständiger XML-Beschreibung) 2. Laufende VM → ausgeschalteter VM 3. Ausgeschaltete VM → laufende VM 4. Änderung an der Beschreibung, insbesonderen Speichergröße, CPU-Anzahl, Device-Konfiguration svn8989, libvirt_0.8.7-1.63.201103212001 svn23107, univention-virtual-machine-manager-daemon_0.9.194-1.203.201103220840 ChangeLog: \item Bei Verwendung von KVM ist die Konfiguration der virtuellen Maschine nun ebenfalls Bestandteil des Sicherungspunktes (\ucsBug{21636}).
Da war noch ein Speicherleck durch eine nicht freigegebenen XML-Beschreibung. svn8991, libvirt_0.8.7-1.65.201103220942
Aktuell kann ich keine Sicherungspunkte mehr wiederherstellen, sofern die Maschine zum Zeitpunkt der Wiederherstellung ausgeschaltet ist. Dieses Verhalten ist unabhängig davon, ob ich Einstellungen verändere oder nicht. Host nutzt KVM, 64Bit. libvirt in Version 0.8.7-1.67.201103221556 Nach dem Wiederherstellen des Sicherungspunktes "läuft" die VM laut UVMM, ich bekomme allerdings keinen "Direktzugriff". In virsh wird die VM als "running" angezeigt, allerdings hat sie keine ID bekommen. Ein "stop" schlägt über virsh und UVMM fehl, da die Maschine nicht läuft. Ein "start" via virsh startet die Maschine regulär (ohne Sicherungsstand). reopen
Da war noch ein logik-Bug in der Implementierung, so daß der Sicherungspunkt im Falle von stopped→running nicht gestartet wurde. Das ist jetzt korrigiert und hat in meinen Tests jetzt auch funktioniert. svn8999, libvirt_0.8.7-1.68.201103232017 Keine Änderung am ChangeLog-Eintrag gemacht.
Da stimmt leider noch etwas scheinbar nicht. Passe ich den Arbeitsspeicher einer Maschine an und reverte im ausgeschalteten Zustand auf einen (laufenden) Sicherungspunkt, so startet die Instanz "regulär" (normaler Boot). In der Log sehe ich folgendes: qemu: warning: error while loading state for instance 0x0 of device 'ram' kvm.bin: Error -22 while loading VM state Ändere ich den Arbeitsspeicher und starte die VM mit neuen Settings und führe den Revert erst dann aus, so funktioniert alles wie erwartet.
(In reply to comment #11) > Da stimmt leider noch etwas scheinbar nicht. > Passe ich den Arbeitsspeicher einer Maschine an und reverte im ausgeschalteten > Zustand auf einen (laufenden) Sicherungspunkt, so startet die Instanz "regulär" > (normaler Boot). running → snapshot → stop → change memory → revert: BUG > Ändere ich den Arbeitsspeicher und starte die VM mit neuen Settings und führe > den Revert erst dann aus, so funktioniert alles wie erwartet. running → snapshot → stop → change memory → start → revert: OK Analyse: Nach einem Revert werden die Snapshot-XML-Daten neu geschrieben, um den aktuellen Zustand zu kennzeichnen. Dabei werden wohl auch noch ein paar andere Daten wie die aktuelle Hauptspeichergröße auf den aktuellen Stand gebracht. Fix: Die Domain-XML-Beschreibung wird nun nur noch einmalig beim ersten Anlegen des Snapshots gesichert und bei allen weiteren Schreibvorgängen wiederverwendet. Das hatte jetzt sogar den nützlichen Nebeneffekt, daß jetzt weniger Stellen im Upstream-Code angepasst werden müssen. svn9002, libvirt_0.8.7-1.69.201103251902
(In reply to comment #12) > running → snapshot → stop → change memory → revert: BUG Das ist jetzt auch behoben - andere denkbare Szenarien wurden erneut erfolgreich getestet. Changelogeintrag vorhanden - 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".