KVM verzeichnet Geländegewinne - Seite 3

Libvirt vereinfacht das Management

Alle in diesem Artikel behandelten Beispiele benutzen das Libvirt-Toolkit [3] unter Fedora 10, das auch in anderen Distributionen zur Verfügung steht (Abbildung 4). Hierbei handelt es sich um eine Art Virtualisierungslayer zwischen dem eigentlichen Virtualisierungsbackend und dem Userspace in Form von Management-Tools (siehe Kasten "Images konvertieren"). Libvirt unterstützt als Backends neben Xen und KVM zurzeit auch noch LXC und OpenVZ. Mit »virt-manager«, »virt-install« und »virsh« stehen Tools bereit, mit denen sich unabhängig vom Virtualisierungsbackend neue Systeme einrichten, verwalten und monitoren lassen. Auch der sichere Zugriff auf einen Remote-Hypervisor ist mittels TLS oder X.509-Zertifikaten möglich. Zur Authentifizierung greift Libvirt auf SASL und Kerberos zurück.

Abbildung 4: Über den »virt-manager« lassen sich auch neue Hardware-Ressourcen zu einer bereits installierten Maschine hinzufügen.

Über eine recht neue Funktion kann Libvirt auch Festplatten-Speicherpools erzeugen. So lassen sich diverse Blockgeräte aus einem Netzwerk (NFS-Server, I-SCSI-Server, LVM-Gruppen) zu einem einheitlichen Pool zusammenfassen, auf den der Admin bei der Konfiguration virtueller Maschinen zurückgreift. Außerdem vereinfacht Libvirt die Netzwerkkonfiguration für die virtuellen Maschinen. So ist es beispielsweise mit »virt-manager« sehr einfach möglich, beliebige private Netzwerke den einzelnen Maschinen zuzuweisen und sie mittels einer Adressen-Umsetzung (Network Address Translation, NAT) mit der Außenwelt zu verbinden.

Alle Einstellungen, die der Admin mit diesem Tool vornimmt, darf jedes unterstütze Virtualisierungsbackend verwenden. Das heißt, man muss sich nicht mehr mit jeweils spezifischen Konfigurationstools für die verschiedenen Backends herumschlagen, wenn das Backend seinerseits die Libvirt verwendet.

Images konvertieren
Das Libvirt-Toolkit erzeugt für jede virtuelle Maschine, und zwar unabhängig vom eingesetzten Hypervisor, eine XML-Datei, die die Eigenschaften der virtuellen Maschine definiert, also beispielsweise wie viel RAM die Maschine bekommen soll oder ob als Speicher-Backend ein Blockgerät oder doch eine Imagedatei zu verwenden ist. Mit dem Einsatz von »virt-convert« ist es möglich, virtuelle Maschinen anderer Formate in ein Libvirt-kompatibles Format zu bringen. Es unterstützt das VMX-Format von VMware. Der folgende Aufruf generiert eine Libvirt-konforme XML-Datei: virt-convert -v -i vmx --os-type=windows --os-variant=winxp winxp.vmx Das Tool erzeugt im selben Ordner eine XML-Datei, die der Admin dann an das Werkzeug »virt-image« übergeben kann, um anhand der vorhandenen Informationen ein neues virtuelles System-Image zu generieren. Benötigt das Tool weitere Informationen, so fragt es sie interaktiv ab: virt-image --name winxp --vnc -i winxp.xml Beide genannten Tools sind im RPM-Paket »python-virtinst« enthalten und gehören seit Fedora 10 zum "Standard Fedora Software Repository". Anders sieht es beim Tool »virt-p2v« aus. Hierbei handelt es sich um eine Live-CD, die es unter [6] zum Download gibt. Mit Hilfe von »virt-p2v« lassen sich komplette Installationen von physikalischen Maschinen in ein virtuelles Maschinenabbild übertragen. Hierzu bootet man das betreffende System von der Virt-p2v-Live-CD und beantwortet einige Fragen zur betreffenden Installation. Anschließend erstellt die CD ein Abbild der Maschine und sendet es über SSH an einen Libvirt-Host (mit Xen oder KVM als Hypervisor). Auf einem Xen-Host findet man das fertige Abbild mit einer Libvirt-konformen Konfigurationsdatei im Verzeichnis »/var/lib/xen/images/«. Von dort aus lässt sich die virtuelle Maschine wie folgt aktivieren: virsh define p2v-rhel5u2-200812231735.conf virsh start rhel5u2 Im Ergebnis läuft eine virtuelle Maschine, die der physischen entspricht.

Images konvertieren

Das Libvirt-Toolkit erzeugt für jede virtuelle Maschine, und zwar unabhängig vom eingesetzten Hypervisor, eine XML-Datei, die die Eigenschaften der virtuellen Maschine definiert, also beispielsweise wie viel RAM die Maschine bekommen soll oder ob als Speicher-Backend ein Blockgerät oder doch eine Imagedatei zu verwenden ist.

Mit dem Einsatz von »virt-convert« ist es möglich, virtuelle Maschinen anderer Formate in ein Libvirt-kompatibles Format zu bringen. Es unterstützt das VMX-Format von VMware. Der folgende Aufruf generiert eine Libvirt-konforme XML-Datei:

virt-convert -v -i vmx --os-type=windows --os-variant=winxp winxp.vmx

Das Tool erzeugt im selben Ordner eine XML-Datei, die der Admin dann an das Werkzeug »virt-image« übergeben kann, um anhand der vorhandenen Informationen ein neues virtuelles System-Image zu generieren. Benötigt das Tool weitere Informationen, so fragt es sie interaktiv ab:

virt-image --name winxp --vnc -i winxp.xml

Beide genannten Tools sind im RPM-Paket »python-virtinst« enthalten und gehören seit Fedora 10 zum "Standard Fedora Software Repository". Anders sieht es beim Tool »virt-p2v« aus. Hierbei handelt es sich um eine Live-CD, die es unter [6] zum Download gibt. Mit Hilfe von »virt-p2v« lassen sich komplette Installationen von physikalischen Maschinen in ein virtuelles Maschinenabbild übertragen. Hierzu bootet man das betreffende System von der Virt-p2v-Live-CD und beantwortet einige Fragen zur betreffenden Installation. Anschließend erstellt die CD ein Abbild der Maschine und sendet es über SSH an einen Libvirt-Host (mit Xen oder KVM als Hypervisor).

Auf einem Xen-Host findet man das fertige Abbild mit einer Libvirt-konformen Konfigurationsdatei im Verzeichnis »/var/lib/xen/images/«. Von dort aus lässt sich die virtuelle Maschine wie folgt aktivieren:

virsh define p2v-rhel5u2-200812231735.conf
virsh start rhel5u2

Im Ergebnis läuft eine virtuelle Maschine, die der physischen entspricht.

In der Praxis

In den folgenden Beispielen geht es um die Installation einer KVM-Instanz. Die virtuelle Maschine für das Beispiel lässt sich leicht mittels »virt-manager« installieren. Neben dem Namen der Maschine sind dafür auch die Installationsquelle, der Arbeitsspeicher und die Anzahl der virtuellen CPUs (VCPUs) anzugeben. Beim Storagebackend stehen eine Imagedatei im Ordner »/var/lib/libvirt/images« und eine reguläres Blockdevice zur Auswahl. Ansonsten ist daran zu denken, den SE-Linux-Typ für die Datei korrekt zu setzen:

[root@tiffy ~]# semanage fcontext -a -t virt_image_t '/Pfad/zur/Image-Datei' 
[root@tiffy ~]# restorecon -v '/Pfad/zur/Image-Datei'

Wählt man als Backend ein Blockdevice, so darf es sich dabei auch um ein Logical Volume (LV) handeln. LVs bieten den Vorteil, dass sie sich problemlos in ihrer Größe verändern lassen und dass Snapshots die Datensicherung ungemein vereinfachen. Bevor der Installer des Systems startet, ist jedoch noch das Netzwerk der virtuellen Maschine einzurichten.