Live-Snapshots mit Virtual Machine Manager

Snapshots virtueller Maschinen sind aus dem Alltag des Systemverwalters kaum mehr wegzudenken. Ein Schnappschuss friert den Zustand einer virtuellen Maschine ein und schreibt ihn auf die Festplatte. Snapshots sind je nach Typ und Anwendungszweck auf ganz verschiedene Arten nützlich. So ermöglichen es Snapshots, immer wieder zum gleichen Zustand einer virtuellen Maschine zurückzukehren, ohne dafür mehrere VMs zu erstellen. Ein via Snapshot erzeugter Wiederherstellungspunkt bewahrt also deren Ausgangszustand, bevor ein Entwickler oder Admin weitere Veränderungen an der VM vornimmt. Aus diesem Grunde nutzen Entwickler gerne Schnappschüsse.

Snapshots sind auch ein Hilfsmittel beim Patchen von Anwendungen oder Servern. So nutzen Administratoren Snapshots gerne, wenn sich der Verdacht eines Konfigurationsfehlers einstellt oder sich das Ableben einer Hardware-Komponente abzeichnet. Auch bei Penetrationsverdacht beziehungsweise als Beweissicherungsmittel in der Forensik kann ein VM-Snapshot als Werkzeug dienen. Außerdem können Admins zum Beispiel beim VM-Checkpointing beliebig viele Snapshots ihrer VM erstellen und bei Bedarf auf mehrere Wiederherstellungspunkte zurückgreifen.

Interne und externe Snapshots

Die verschiedene Arten von Schnappschüssen unterscheiden sich zum Beispiel darin, ob auch der Zustand des Arbeitsspeichers und des Dateisystems der VM eingefroren wird. Alle namhaften Virtualisierungslösungen unterstützen heute Snapshots. Dieser Beitrag widmet sich der Art von Snapshots, die unter Linux die Libvirt-Abstraktionsebene zur Verfügung stellt, speziell diejenigen, die sich über das grafische Frontend Virtual Machine Manager [1] nutzen lassen.

Allgemein unterscheiden Qemu [2] beziehungsweise Libvirt [3] interne und externe Snapshots. Bei internen Snapshots friert Libvirt den vollständigen Zustand der laufenden virtuellem Maschine ein und schreibt den Snapshot direkt in die Image-Datei der virtuellen Festplatte. Dies umfasst den Zustand des Hauptspeicherinhalts der virtuellen Maschine, den Zustand der virtuellen Geräte und den Zustand der virtuellen Festplatte.

Lediglich die zum Zugriff einer Verwaltungsoberfläche wie VMM auf die Wiederherstellungspunkte benötigten XML-Dateien sind bei einer per Default mit dem lokalen Hypervisor verbundenen Libvirt unter »/var/lib/libvirt/qemu/snapshot/VM« abgelegt. Interne Snapshots funktionieren allerdings nur, wenn der Admin beim Definieren der virtuellen Maschine für die virtuelle Festplatte das QCOW2-Format benutzt, das »Copy-On-Write« unterstützt. Zum Ändern des Image-Formats schaltet der Admin beim Virtual Machine Manager von der Konsolen- in die Detail-Ansicht um und klappt beim links markierten Disk-Gerät die »Erweiterten Optionen« auf ( Abbildung 1 ).

Abbildung 1: Interne (Live-)Snapshots funktionieren nur mit dem QCOW2-Format.

Interne Snapshots lassen sich allerdings nicht ohne Weiteres sichern, weil sie ja im Image stecken und die virtuelle Maschine in der Regel weiterläuft. Der Admin könnte die virtuelle Maschine dazu lediglich kurzfristig anhalten und das komplette Image sichern.

Alternativ kennt Libvirt auch »externe Snapshots« , bei denen der Inhalt des Hauptspeichers in einer anzugebenden Datei landet, das ursprüngliche Festplatten-Image eingefroren und Änderungen fortan in ein neues Image geschrieben werden. Externe Snapshot (Live-Checkpointing) erschließen sich dem Admin allerdings ausschließlich über die Virsh. Weitere Details dazu erläutert ein Artikel im Linux Magazin 01/2014 [4] .

Der Anlass, Live-Shapshots jetzt zu thematisieren, ist die mit Fedora 20 ausgelieferte Version des grafischen Virtual Machine Managers, der unter Fedora 20 auch interne Snapshots unterstützt. Wer einwenden möchte, VMM beherrsche bereits Snapshots, weil auch bei älteren Versionen im Klappmenü zum Beenden einer virtuellen Maschine als Option »Speichern« zur Verfügung stehe, der irrt – jedenfalls ein bisschen.

Diese Funktion friert in der Tat den Zustand der betreffenden virtuellen Maschine ein und schreibt den Inhalt des Hauptspeichers der VM in das Festplatten-Image. Allerdings schaltet die Funktion die virtuelle Maschine nach dem Einfrieren auf Festplatte komplett aus und ist daher nichts anderes, als ein mit dem Stomsparmodus Supend-to-Disk vergleichbares Verfahren, sodass VMM beim nächsten Start der VM unmittelbar zum letzten Zustand zurückkehren kann. Dabei hat das Betriebssystem in der VM allerdings keine Kenntnis von dem Vorgang, weil dieser – von VMM initiiert – vollständig von Libvirt gesteuert wird.

Der Nachteil gegenüber der erst jetzt in VMM implementierten Unterstützung interner Snapshots besteht darin, dass die virtuelle Maschine nach dem Einfrieren abgeschaltet wird. Damit scheidet die Methode zum Beispiel als Sicherungsnetz für Entwickler oder für Admins, die ein sich abzeichnendes Konfigurations- oder Hardware-Problem einkreisen wollen, aus. Übrigens erstellt die Funktion stets nur eine Sicherung und entfernt diese beim nächsten Start der VM wieder. Sie ist aber wie ein gewöhnliches Suspend-to-Disk auf physischer Hardware nützlich, um den nächsten Startvorgang zu beschleunigen.

Interne Snapshots mit VMM

Cole Robinsons Eintrag im Fedora-Wiki [5] erläutert eine ganze Reihe von Snapshot-Parametern im Zusammenhang mit »virsh« , darunter auch Live-Backups. Läuft beispielsweise unter Libvirt eine virtuelle Maschine namens »rhel6« , kann der Admim mit

virsh snapshot-create-as myvm snapshot1 "Mein Snapshot" --disk-only-atomic

ein einfaches Live-Backup mit dem Parameter »--disk-only« erzwingen.

VMM beherrscht seit der mit Fedora implementierten Version aber auch Live-Snaphots. Manuell würde der Admin beispielsweise mit

virsh -c qemu:////system snapshot-create-as rhel6 "snap1" "Die ist einSnapshot von rhel6"

einen internen Schnappschuss starten. Das Kommando quittiert mit »Domain snapshot snap1 created« . Die virtuelle Maschine läuft aber weiter. Startet der Systemverwalter jetzt eine aktuelle Entwicklerversion des Virtual Machine Manager (VMM), sollte der Snapshot unter »Anzeigen Snapshots« auftauchen ( Abbildung 2 ).

Abbildung 2: Die aktuelle Entwicklerversion von VMM zeigt auch existente interne Snapshots an.

Das war nicht immer so. Die momentan reguläre VMM-Version 0.10.0 vom Juni letzten Jahres ist zwar in den Paketquellen der gängigen Distributionen zu finden, unterstützt diese Funktion aber noch nicht, genauso wenig wie das Erzeugen eines internen Snapshots aus der GUI. Das Freischalten der Entwickler-Virtualisierungs-Pakete in Form der Paketquelle »Virtualization packages from Rawhide bild for latest fedora« erlaubt das Installieren der erforderlichen VMM-Version 0.10.5 unter Fedora 19. Wahlweise kann der Admin eine aktuelle VMM-Version jederzeit von Git auschecken.

Die funktioniert unter Fedora 19 allerdings nur, wenn der Systemverwalter im gleichen Aufwasch auch Qemu von Version 1.4.2 auf Version 1.6.1 aus der gleichen Paketquelle aktualisiert. Trotzdem quittierte die frisch installierte Version 0.10.5 den ersten Versuch, ein Gastsystem zu starten, mit der Fehlermeldung »virt-manager can not start guest because can not load libGL.so.1« , ein Problem das sich allerdings relativ schnell als bekannter Bug [6] identifizieren und unter Fedora, CentOS und RHEL derzeit nur durch das Abschalten von SELinux beseitigen ließ. Nach der Eingabe von »setenforce 0« ist es dann auch unter Fedora 19 möglich, interne Snapshots aus dem GUI-Tool anzuschieben. Hierzu wechselt der Admin mit »Anzeigen | Snapshots« von der Konsolenansicht zur aktuellen Snapshot-Liste. Ein Klick auf das Plus-Symbol unten links erzeugt dann einen neuen Snapshot. Hier ist nicht mehr zu tun, als einen Name für den Snapshot und eine Beschreibung zu hinterlegen.

Diese Beschreibung (und nur sie!) lässt sich auch im Nachhinein ändern. Mit einen Fortschrittsbalken signalisiert VMM, wann das Einfrieren der virtuellen Maschine beendet ist. VMM nimmt dann den fertigen Snapshot mitsamt eines Screenshots in die Liste auf.

Klickt man einen existenten Snapshot in der Liste links an, sieht man rechts das Erstellungsdatum (Timestamp) und den Namen des Snapshots und außerdem, ob die virtuelle Maschine nach dem Erstellen des Snapshots weiterläuft. Ist das der Fall (Default in VMM) und wurde beim Anlegen ein Screenshot erzeugt, ist der ebenfalls zu sehen.

Da VMM allerdings auch von Hand erzeugte interne Snapshots anzeigt, könnten hier auch solche auftauchen, bei denen die virtuelle Maschine anhält. Für das Zurückkehren zu einem existenten Snapshot steht unten links neben dem Plus-Symbol das Abspielen-Symbol zur Verfügung, deren Zustand VMM sofort nach dem Bestätigen der Sicherheitsabfrage wiederherstellt ( Abbildung 3 ).

Abbildung 3: Das Wiederherstellen eines Snapshots.