© Ivan Smuk, 123RF.com

In der aktuellen Entwicklerversion kann der Virtual Machine Manager (Virt-Manager) endlich seine virtuellen Maschinen einfrieren und als so genannten Snapshot abspeichern. Das klappt auf zwei verschiedene Arten, die aber ihre Vor- und Nachteile haben. Mit der Kommandozeile gelingt das sicherer.

Fast alle Virtualisierungslösungen können ihre virtuellen Maschinen einfrieren und dann mit Haut und Haaren auf der Festplatte abspeichern. Dieses Vorgehen bezeichnet man als Schnappschuss. Nach dem Wiederherstellen eines solchen Snapshots arbeitet die virtuelle Maschine genau dort weiter, wo sie der Administrator beim Einfrieren unterbrochen hatte.Das Laden der Snapshots gelingt in der Regel deutlich flotter, als das System neu zu booten.

Flotter Maschinenpark

Mit einem Snapshot lässt sich nicht nur gezielt ein Ablauf unterbrechen, sondern auch nach einem Defekt oder einem Konfigurationsfehler schnell ein alter, funktionierender Systemzustand wiederherstellen. Entwickler können für ihre Tests mehrere Snapshots vorhalten und so schnell zwischen verschiedenen Konfigurationen hin und her wechseln.

Alles eigentlich keine Magie, doch ließ die Libvirt bisher passende GUI-Tools dafür vermissen. Wer seine virtuellen Maschinen mit dem beliebten Virtual Machine Manager (VMM) oder Virt-Manager verwaltet, blickte lange Zeit in die Röhre. Bis einschließlich Version 0.10.0 konnte das GUI lediglich den Inhalt des Hauptspeichers der virtuellen Maschine einfrieren. Während der Entwicklung von Fedora 20 rüstete jedoch der Entwickler Cole Robinson freundlicherweise eine kleine Snapshot-Verwaltung nach [1].

Sie bietet zwar immer noch nicht den Funktionsumfang des Kommandozeilen-Werkzeugs Virsh, für die meisten Anwendungsfälle sollten die Verwaltungsmöglichkeiten jedoch ausreichen. Im Gegenzug benötigt der Administrator keine kryptischen Kommandos mehr, in VMM genügt jetzt ein Mausklick, um einen neuen Snapshot anzufertigen. Als netten Bonus macht das GUI auch noch automatisch einen Screenshot, wodurch sich erstellte Snapshots wesentlich leichter voneinander unterscheiden lassen als an der Kommandozeile.

Im Gegensatz zum CLI mussten die Tester des Linux-Magazins am GUI allerdings noch einige Kinderkrankheiten diagnostizieren. So klappte die Managed-Save-Option nicht immer, auch das Wiederherstellen machte noch hier und da Probleme. Allerdings existieren zu allen Fällen Bugreports im Fedora-Bugzilla bei Red Hat, sodass für die finale Version noch Hoffnung besteht.

Nur mit Fedora 20

Um die neue Snapshot-Verwaltung auszuprobieren, mussten Administratoren – jedenfalls bei Redaktionsschluss – entweder zu einer Vorabversion von Fedora 20 greifen oder den Quellcode aus dem VMM-Git-Repository selbst übersetzen [2]. In beiden Fällen erhielten sie lediglich eine Entwicklerversion von VMM. Verwirrung herrschte zudem bei der Nummerierung: Der VMM in der Beta von Fedora 20 trug die Versionsnummer 0.10.0-5, während die auf der VMM-Homepage angebotene Version 0.10.0 noch nicht mit Snapshots umgeben konnte.

Eingelegtes Kurzzeitgedächtnis

Um Snapshots mit VMM zu erstellen, ruft der Administrator zunächst die Detailansicht der virtuellen Maschine auf, etwa über »Bearbeiten | Details der virtuellen Maschine« . Dort lässt sich jetzt ein Snapshot auf zwei Arten anfertigen. Die erste Variante funktioniert auch unter älteren VMM-Versionen: Der Administrator aktiviert einfach den Menüpunkt »Virtuelle Maschine | Herunterfahren | Speichern« . VMM friert jetzt die Maschine ein, schreibt den Hauptspeicherinhalt in das Festplattenimage und schaltet die virtuelle Maschine aus.

Suspend

Bei jedem erneuten Start der virtuellen Maschine (beispielsweise via »Virtuelle Maschine | Ausführen« ) stellt VMM automatisch den alten Zustand wieder her. Der komplette Vorgang ist vergleichbar mit dem Stromsparmodus Suspend to Disk, wobei hier jedoch VMM beziehungsweise das von ihm beauftragte Libvirt die Sicherung erstellt. Das Betriebssystem in der virtuellen Maschine bekommt von dem ganzen Vorgang nichts mit.

Das Speichern einer virtuellen Maschine hat jedoch gleich mehrere Nachteile: Zunächst friert VMM das System ein, nach der Sicherung läuft es nicht automatisch weiter. Arbeitet in der virtuellen Maschine ein Webserver, ist dieser also vorübergehend nicht mehr erreichbar.

Darüber hinaus lässt sich immer nur genau eine Sicherung erstellen, die zudem VMM direkt nach dem nächsten Start der virtuellen Maschine wieder löscht. Das Speichern einer virtuellen Maschine ist daher nur sinnvoll, wenn der Administrator einen Vorgang unterbrechen möchte – beispielsweise weil er eine Kopie der virtuellen Maschine anfertigt.

Bitte recht freundlich

Die mit Fedora 20 eingeführte Version von VMM kann jedoch auch das komplette System einschließlich der Festplatten im laufenden Betrieb als Snapshot speichern (Variante 2). Jeder Schnappschuss erhält dabei einen eigenen Namen und lässt sich jederzeit und vor allem beliebig oft wiederherstellen. Alle derartigen Snapshots verwaltet der Admin hinter »Anzeigen | Snapshots« . In der standardmäßig noch leeren Liste am linken Rand sammelt VMM alle Snapshots.

Um einen neuen Snapshot zu erhalten, klickt der Administrator auf das Plus-Symbol links unten in der Fensterecke. Im folgenden Formular muss er dem Snapshot lediglich noch einen Namen und bei Bedarf eine Beschreibung verpassen (Abbildung 1). Neben »Status« vermerkt VMM noch einmal, ob die virtuelle Maschine gerade ausgeschaltet ist oder läuft. Einen Screenshot erstellt VMM übrigens nur im letzten Fall. Nach einem Klick auf »Abschließen« lässt VMM von Libvirt den Snapshot erzeugen (Abbildung 2).

Abbildung 1: Beim Anlegen eines Snapshots muss man nur einen Namen vergeben, den Screenshot schießt VMM automatisch.

Abbildung 2: Die neue Snapshot-Verwaltung ist einfach, für die meisten Aufgaben aber ausreichend.

Stolpersteine

Dabei speichert Libvirt innerhalb ihres Festplattenimage den aktuellen Zustand der virtuellen Festplatte, den kompletten Hauptspeicherinhalt und den Zustand der (virtuellen) Geräte der virtuellen Maschine. Solche Schnappschüsse heißen deshalb auch interne Snapshots. Damit das funktioniert, muss allerdings das Festplattenimage ein Dateiformat verwenden, das Snapshots unterstützt. Das ist derzeit bei Qcow2 und dessen designiertem Nachfolger QED der Fall, nicht jedoch etwa bei Images im Raw-Format oder aus Virtualbox, also solchen mit der Dateinamenserweiterung ».vdi« .

Kann das Image nicht mit Snapshots umgehen, schaltet VMM die Snapshot-Verwaltung ab. In solchen Fällen sollte der Admin als primäre Fehlerquelle das Dateiformat überprüfen. In VMM erhält er die entsprechende Information, indem er »Anzeigen | Details« aufruft, die Festplatte anklickt (in der Regel »IDE Disk 1« ), dann »Erweiterte Optionen« öffnet und einen Blick auf das »Speicherformat« wirft. Alternativ lässt sich auch das Werkzeug »qemu-img« auf das Plattenimage ansetzen (Abbildung 3):

Abbildung 3: »qemu-img« liefert nicht nur das Dateiformat des Image (hier »qcow2«), sondern verrät auch, welche Snapshots darin gespeichert sind.

qemu-img info /var/lib/libvirt/images/platte.img

Dass die Snapshots im Festplattenimage landen, ist zwar bequem, erschwert jedoch das Backup: Admins müssen zwangsweise das Image komplett sichern und dazu wiederum die virtuelle Maschine vorübergehend anhalten. Beim Klonen einer virtuellen Maschine klont VMM zudem die Snapshots nicht mit, es bleibt nichts übrig, als sie im Klon erneut anzulegen.

Konnte VMM den Snapshot erstellen, erscheint er in der Liste am linken Rand. Klickt der Administrator dort einen Snapshot an, erfährt er auf der rechten Seite den Namen, das Erstellungsdatum und ob die virtuelle Maschine nach der Wiederherstellung des Snapshots läuft oder ausgeschaltet ist. Im Gegensatz zum Namen darf der Administrator die »Beschreibung« nachträglich anpassen. Unter der Beschreibung zeigt VMM noch den Screenshot an – vorausgesetzt es konnte einen solchen anfertigen.

Wer einen Snapshot wiederherstellen möchte, markiert ihn in der Liste und klickt dann am unteren Fensterrand auf das Symbol mit dem weißen Dreieck und bestätigt die Rückfrage. Das Symbol mit dem roten Kreis und dem X würde hingegen den markierten Snapshot löschen. Die Liste mit den Snapshots sortiert VMM übrigens eigenmächtig alphabetisch aufsteigend.

Tippse

Mehr Funktionen und Möglichkeiten als VMM bietet das Kommandozeilen-Werkzeug Virsh, das ja auch schon seit Urzeiten mit Snapshots umgehen kann. Die grundlegende Bedienung von Virsh erläuterte ein Artikel im Linux-Magazin [3]. Läuft die virtuelle Maschine namens »debian« unter KVM auf dem aktuellen Rechner, erzeugt der folgende Befehl von ihr einen Snapshot mit dem Namen »snaptest« und der Beschreibung »Ein erster Snapshot« :

virsh -c qemu:///system snapshot-create-as debian "snaptest" "Ein erster Snapshot"

Ein derart über Virsh initiierter Snapshot taucht übrigens erst dann im VMM auf, wenn der Administrator diesen neu startet. Dabei reicht es nicht aus, nur die Detailansicht der virtuellen Maschine zu schließen.

Im Gegensatz zu VMM lässt sich das Erzeugen eines Snapshots über Virsh noch beeinflussen: Steht hinter »debian« der Parameter »–halt« , läuft die virtuelle Maschine nicht einfach weiter, sondern verbleibt nach dem Snapshot in einem inaktiven Zustand. Fügt der Admin ganz am Ende noch »–disc-only« hinzu, friert Virsh sogar nur den Stand der Festplatten ein.

Welche Snapshots für die virtuelle Maschine »debian« vorliegen, verrät dieser Befehl (Abbildung 4):

Abbildung 4: Hier besitzt die virtuelle Maschine namens »vm1« fünf Snapshots.

virsh -c qemu:///system snapshot-list debian

Den Snapshot namens »snaptest« stellt das Kommando

virsh -c qemu:///system snapshot-revert debian snaptest

wieder her. Analog löscht der folgende Befehl den Snapshot »snaptest« :

virsh -c qemu:///system snapshot-delete debian snaptest

Wie VMM fertigt auch Virsh mit dem Kommando »snapshot-create-as« einen internen Snapshot an. Alle relevanten Daten einschließlich des Hauptspeicherinhalts landen folglich im Festplattenimage der virtuellen Maschine.

Virsh kann jedoch auch Snapshots in externen Dateien speichern. Einen solchen so genannten externen Snapshot mit dem Namen »snap1« erstellt das Kommando aus Listing 1. Der Inhalt des Hauptspeichers landet dabei in der Datei »ram-snap1« . Das alte Festplattenimage friert Virsh zudem ein, alle Änderungen landen ab sofort in der Datei »aenderungen-snap1.qcow2« . Das »hda« hinter »–diskspec« steht für den Gerätenamen der Festplatte. Ihn verrät für die virtuelle Maschine »debian« der Befehl:

01 virsh -c qemu:///system snapshot-create-as --domain debian "snap1" "Ein externer Snapshot" --diskspec hda,snapshot=external,file=/var/lib/libvirt/images/aenderungen-snap1.qcow2 --memspec file=/var/lib/libvirt/images/ram-snap1,snapshot=external

virsh -c qemu:///system domblklist debian

Er listet zu jedem in der virtuellen Maschine genutzten Image und Laufwerk die jeweiligen Gerätenamen auf (siehe Abbildung 5).

Abbildung 5: Das Virsh-Kommando »domblklist« zeigt Blockdevices an. In diesem Beispiel hat die virtuelle Maschine »vm1« zwei Laufwerke.

Führungskraft

Virsh kann nicht nur Snapshots, sondern auch wie VMM den aktuellen Zustand speichern. Für die laufende virtuelle Maschine namens »debian« erledigt dies:

virsh -c qemu:///system managedsave debian

Über das Kommando

virsh -c qemu:///system managedsave-remove debian

darf der Admin den gemerkten Zustand auch explizit verwerfen – VMM erlaubt dies nicht.

Wer in der Manpage von Virsh stöbert, trifft dort neben »mangedsave« auch auf das Kommando »save« . Es sichert ebenfalls den RAM-Inhalt der virtuellen Maschine, im Gegensatz zu »managedsave« jedoch in einer externen Datei. In folgendem Beispiel würde sich Virsh den aktuellen Zustand der virtuellen Maschine »debian« in der Datei »/var/lib/libvirt/images/ram-snap1« merken:

virsh -c qemu:///system save debian /var/lib/libvirt/images/ram-snap1

Den so gespeicherten Hauptspeicherinhalt stellt dann das Kommando

virsh -c qemu:///system restore /var/lib/libvirt/images/ram-snap1

wieder her. Den Namen der virtuellen Maschine muss der Admin hier weglassen. »save« und »restore« scheinen auf den ersten Blick vorteilhafter als »managedsave« zu sein. So lassen sich beliebig viele Sicherungen des Hauptspeicherinhalts anlegen und dann bei Bedarf eine von ihnen wiederherstellen. Dummerweise sichern Virsh beziehungsweise das im Hintergrund damit beauftragte Libvirt nicht die Festplatte.

Wer also mit »save« sichert, dann mit dem System weiterarbeitet und irgendwann die Sicherung per »restore« wieder herstellt, sitzt vor einer virtuellen Maschine mit einem undefinierten Zustand. Im schlimmsten Fall kommt es zu Datenverlust. »save« und »restore« eignen sich daher nur bei Livesystemen oder ähnlichen Sonderfällen.

Gut dokumentiert und überfällig

Sämtliche Virsh-Kommandos stellt die ausführliche Manpage von Virsh vor. Alle Snapshot-Kommandos sammelt sie im Abschnitt »Snapshot Commands« [4], »save« , »restore« und »managedsave« stehen unter »Domain Commands« .

Die Unterstützung für Snapshots in VMM war längt überfällig, helfen sie doch in der Praxis dabei, das System nach einer (Fehl-)Konfiguration schnell, sicher und unkompliziert wieder in einen funktionierenden Zustand zu versetzen.

Bei der Nutzung muss man allerdings ein paar Einschränkungen im Hinterkopf behalten. So fertigt VMM ausschließlich interne Snapshots an, die sich nicht ohne Weiteres als Systembackups eignen. VMM schöpft zudem längst nicht alle Möglichkeiten aus, die das von ihm gesteuerte Libvirt eigentlich anbietet. Externe Snapshots etwa beherrscht weiterhin nur Virsh. Bleibt zu hoffen, dass die VMM-Entwickler hier mittelfristig nachbessern.