© kay_1, photocase.com

Wer mit der Bibliothek Libvirt seine virtuellen Maschinen jongliert, findet das kleine Kommandozeilen-Werkzeug virsh auf der Festplatte. Es fragt blitzschnell die virtuelle Maschine nach ihrem Befinden, startet sie oder fährt sie herunter. Bequem sind diese Tasks in Skripte einzubinden.

Das Libvirt-Projekt hat es sich zum Ziel gesetzt, eine einheitliche Verwaltungszentrale für unterschiedliche Virtualisierungslösungen und Hypervisoren zu schaffen [1]. In der Praxis kennen es viele Administratoren nur als die bunte Oberfläche »virt-manager« , die virtuelle Maschinen mit Qemu/KVM verwaltet. Dabei gehört der »virt-manager« gar nicht zum Libvirt-Projekt. Letzteres liefert nur eine Handvoll Kommandozeilen-Programme aus. Darunter befindet sich auch das zu Unrecht übersehene, in vielen Lebenslagen äußerst nützliche »virsh« .

Bauhaus

Wie alle anderen Libvirt-Werkzeuge, basiert »virsh« auf der Libvirt-Bibliothek. Die bildet wiederum die Schnittstelle zum »libvirtd« -Daemon. Er läuft auf dem Rechner mit den virtuellen Maschinen, dem so genannten Knoten (Node), und übernimmt die eigentliche Steuerung der Hypervisoren. Libvirtd ist somit gewissermaßen der verlängerte Arm des Admin. Das Zusammenspiel verdeutlicht Abbildung 1.

Abbildung 1: Virsh leitet die Befehle an die übrigen Komponenten des Libvirt-Pakets weiter.

Nach der Installation von »libvirt« lässt sich »virsh« sofort nutzen – normalerweise. Viele Distributionen lagern Libvirt-Tools in ein eigenes Paket aus. Dazu gehören Debian und Ubuntu, bei denen der Admin »virsh« unter Umständen erst über das Paket »libvirt-bin« hinzuholen muss. Unter Open Suse heißt das Pendant »libvirt-client« .

Ob das so auf der Platte angekommene Progrämmchen einsatzfähig ist, prüft die Eingabe von »virsh version« . Gibt es eine Fehlermeldung, sollte der Nutzer sich Rootrechte beschaffen und sein Glück erneut probieren. Fabuliert »virsh« etwas von einem Verbindungsfehler, gilt es, noch den Libvirtd-Daemon zu aktivieren. Die meisten Distributionen starten ihn zwar automatisch mit der Installation der Libvirt-Pakete. Manchmal ist aber Handarbeit gefragt, unter Open Suse 11.3 per »rclibvirtd start« . Nun sollte »virsh version« aber brav die Versionsnummern der beteiligten Komponenten ausspucken und auf weitere Befehle warten.

URIg

Einen Überblick über die gerade laufenden virtuellen Maschinen verschafft die Eingabe der Zeile:

virsh -c qemu:///system list --all

Sie verbindet Virsh (»-c« für Connect) mit Qemu auf dem aktuellen System und »list« -et alle vorhandenen virtuellen Maschinen auf, darunter die laufenden und die pausierten (»–all« ). Das kryptische »qemu:///system« ist ein Uniform Resource Identifier (URI), der »virsh« die genutzte Virtualisierungslösung mitteilt. Im Beispiel ist dies Qemu/KVM. Tabelle 1 zeigt weitere mögliche URIs. Libvirt und somit auch »virsh« steuern prinzipiell die virtuellen Maschinen von Qemu/KVM, Xen, LXC, Open VZ, Virtualbox, Microsoft Hyper-V sowie VMware ESX, GSX, Workstation und Player.

Dies setzt aber voraus, dass Libvirt mit entsprechender Unterstützung übersetzt wurde (oder die entsprechenden Treiber vorhanden sind). In den Libvirt-Paketen der Distributionen schlummern häufig nur Fassungen, die mit Qemu/KVM umgehen können. Die folgenden Beispiele beschränken sich auf diese Virtualisierungslösung.

Sofern die virtuellen Maschinen auf einem entfernten Rechner vor sich hin werkeln, integriert der Administrator noch die IP-Adresse beziehungsweise den Domainnamen in den URI. Der Befehl

virsh -c qemu://example.com/systemlist --all

gibt eine Liste aller auf dem Rechner »example.com« laufenden virtuellen Maschinen aus. Falls nötig, gibt der Admin noch die Verbindungsart an:

virsh -c qemu+ssh://admin example.com/?
system list --all

In diesem Beispiel verbindet sich »virsh« mit dem Rechner »example.com« und mit dem Benutzer »admin« über eine gesicherte SSH-Verbindung. Weitere Beispiele zum Aufbau der URIs zeigt [2].

virt-top -c qemu:///system

Um Tipparbeit zu sparen, legt man den URI in der Umgebungsvariablen »VIRSH _DEFAULT_CONNECT_URI« ab und braucht ihn künftig beim Aufruf von »virsh« nicht mehr:

export VIRSH_DEFAULT_CONNECT_URI?
=qemu:///system
virsh list --all

Konkretere Informationen zur virtuellen Maschine »debian« liefert:

virsh -c qemu:///system dominfo debian

Den aktuellen Zustand des Gastrechners zeigt

virsh -c qemu:///system nodeinfo

dem Admin an (siehe Abbildung 2).

Abbildung 2: Auf diesem Rechner laufen zwei virtuelle Maschinen, die mit dem Namen »debian[UCC:x00-fake-italic]« nutzt nur eine CPU, obwohl der echte Prozessor ihr mehr abgeben könnte. Die Informationen landen in der Standardausgabe und lassen sich dann etwa mit Grep auseinandernehmen.

Ausgeführt

Eine gerade Däumchen drehende virtuelle Maschine mit dem Namen »debian« fährt

virsh -c qemu://system shutdown debian

via ACPI herunter. Sollte die VM nicht darauf reagieren, kann

virsh -c qemu:///system destroy debian

sie auch unsanft töten. Im auf die eine oder andere Art erreichten ausgeschalteten Zustand lässt sich jetzt die Konfiguration der virtuellen Maschine via

virsh -c qemu:///?
system edit debian

einsehen und anpassen. Es startet der Vim und öffnet die zugehörige XML-Datei. Wem der Editor zu spartanisch ist, der schiebt die XML- in eine Textdatei

virsh -c qemu:///system dumpxml?
 debian >/tmp/debian.xml

und verändert diese dann per Hand und erstellt auf ihrer Basis die virtuelle Maschine neu:

virsh -c qemu:///system create /tmp/?
debian.xml

Auf den ersten Blick erscheint dieses Management fummeliger als über eine grafische Oberfläche. Die Befehle lassen sich jedoch in ein (Bash-)Skript einbetten, um so etwa eine ganze Reihe von virtuellen Maschinen halbautomatisch zu starten oder nachträglich umzukonfigurieren.

Schrauber und Schieber

Um die Speichernutzung und die Anzahl der Prozessoren einer virtuellen Maschine zu ändern, braucht der Admin keinen Eingriff in die XML-Datei. Hierfür gibt es jeweils einen praktischen, kurzen Befehl. So weist

virsh -c qemu:///system setmem?
 debian 250000

der VM »debian« 250000 KByte Speicher zu. Dazu spendiert

virsh -c qemu:///system setvcpus debian 2

zwei virtuelle CPUs. Der Einsatz des »migrate« -Befehls schiebt eine virtuelle Maschine auf einen anderen Rechner:

virsh -c qemu:///?
system migrate --livedebian?
 qemu://example.com/system

Dabei wandert die Maschine »debian« auf den Server »example.com« . Das »–live« erzwingt die Migration.

Abbildung 3: »virt-top« verrät kontinuierlich die Auslastung der virtuellen Maschinen.

Muschel

Virsh kennt auch einen interaktiven Modus. Den betritt automatisch, wer Parameter weglässt wie bei »virsh -c quemu///system« . Dort darf er angehängte Befehle ausführen, etwa »list –all« . Ein »quit« kehrt zur Shell zurück. Auf Wunsch wechselt

virsh -c qemu:///system console debian

zu der Konsole einer laufenden virtuellen Maschine.

Fazit

Die Syntax von »virsh« ist gewöhnungsbedürftig. Nach kurzer Probezeit lässt sich das Werkzeug jedoch einfach in eigene Bash-Skripte integrieren. Ein kurzer Statusbericht über alle laufenden Systeme verlangt zudem nur eine Zeile, die schneller abgesetzt ist, als man sich im Virt-Manager zur Statistik durchgeklickt hat. Virsh kennt noch mehr Befehle (Tabelle 2) und Aktionen (siehe Kasten “Alles Top!”). Eine erste Übersicht zeigt »virsh help« , eine lückenhafte Referenz wartet unter [3].