Virtuelle Maschinen mit KVM

Der erste Schritt zur Migration besteht in der Konsolidierung der vorhandenen Hardware. Um diese besser auszunutzen, kommen virtuelle Maschinen zum Einsatz. Vorhandene Dienste laufen dabei innerhalb dieser virtuellen System-Instanzen auf der gleichen Hardware. Als Hypervisor dient entweder Xen [2] oder KVM [3] . Beide Produkte haben sich in der Vergangenheit als stabile Open-Source-Lösungen zur Virtualisierung bewährt. KVM gewinnt als reiner Level-1-Hypervisor immer mehr an Beliebtheit und entspricht allen technischen Anforderungen an einen Hypervisor im Enterprise Umfeld.

Bei KVM handelt es sich um ein Kernel-Modul, das auf den Virtualisierungssupport der eingesetzten CPU angewiesen ist. Wie die Full-Virtualisation aus Basis von Xen benötigt KVM eine Intel-VT oder AMD-V CPU und das passende Kernel-Modul »kvm-intel« beziehungsweise »kvm-amd« . Anders als bei Xen ist der Hypervisor nicht unterhalb des Betriebssystems angesiedelt, sondern das Betriebssystem selbst, in Form des KVM-Kernel-Moduls, ist hier der Hypervisor. Die virtuellen Maschinen laufen dabei als reguläre User-Space-Prozesse und lassen sich über die Geräte-Datei »/dev/kvm« ansprechen. Als Emulator für I/O-Hardware kommt ein modifiziertes »qemu« zum Einsatz.

Aktuelle Virtualisierungstechnologien, wie beispielsweise I/O-MMU (Sicheres PCI pass-through), KSM (Kernel Samgepage Merging) und Virt-I/O (paravirtualisierte I/O-Treiber) unterstützt KVM seit geraumer Zeit. Dank einer Schnittstelle zum Libvirt-Framework [4] ist ein Zugriff auf den Hypervisor über Frontends wie Virt-Manager oder »virsh« möglich. Unter Fedora oder anderen Red-Hat-basierten Systemen befinden sich die beiden Tools in den Paketen »virt-manager« beziehungsweise »libvirt-client« .

Das Libvirt-Framework ist dabei in der Lage, Ressource-Pools für Blockdevices zu erzeugen und zu verwalten. So lassen sich sowohl lokale Festplatten als auch Netzwerkspeicher wie beispielsweise NFS oder auch iSCSI-Geräte zu einem einzelnen großen Pool zusammenfassen. Virtuelle Maschinen können dann beliebige Festplatten aus diesem Pool zugeordnet bekommen. Dabei kann es durchaus passieren, das die Daten dieser Maschinen somit an auf vollkommen unterschiedlichen physikalischen Geräten liegen. Um den Ausfall einer Hardware-Komponente abfangen zu können, sind die virtuellen Maschinen natürlich als hochverfügbare Dienste zu implementieren. Dies ist mit Libvirt ohne weiteres möglich. Beim Einsatz der Red Hat Cluster Suite [5] lassen sich die virtuellen System Instanzen einfach als HA-Services in einen Clusterverbund aufnehmen. Einen ausführlicher Artikel zum Setup von virtuellen Maschinen auf Basis von KVM und Libvirt und der Integration in einen HA-Cluster hat der Autor bereits im ADMIN-Magazin veröffentlicht [6] .

Provisioning mit Spacewalk

Zur Installation der virtuellen Maschinen bietet sich eine Managament Plattform wie Spacewalk [7] an. Spacewalk bietet nicht nur den Vorteil, dass es zum Zeitpunkt der Installation der Systeme als Installationsserver dient, auch im laufenden Betrieb beziehen die Systeme ihre Updates von diesem Server. Natürlich liefert Spacewalk auch gleich die gewünschten Konfigurationsdateien mit aus. Software-Pakete und Konfigurationsdateien sind dabei in Kanälen organisiert. Bei der Anmeldung am Spacewalk-Server bekommt ein System Zugriff auf die gewünschten Kanäle und kann somit Ressourcen aus diesen beziehen. Dabei ist sowohl eine Abfrage der gewünschten Daten vom System aus möglich (Poll-Verfahren), der Admin kann jedoch auch die Software-Pakate und Konfigurationsdateien über ein Webinterface auf die einzelnen Systeme übertragen (Push-Verfahren) ohne im Einzelnen mit diesen verbunden zu sein.

Für die eigentliche Installation eines Systems legt eine so genannte Kickstart-Datei im Einzelnen fest, wie das System ausehen soll. Beispielsweise enthält sie die gewünschte Partitionierung, eine Software-Auswahl und Netzwerkkonfiguration. Für jeden Dienst, der in der eigenen Cloud läuft, ist ein solches Profil auf dem Spacewalk-Server zu hinterlegen. System-spezifische Details lassen sich über eine Skript-Sektion innerhalb eines Profiles erzeugen. Ein beliebter Trick ist hier beispielsweise die übergebenen Kernel-Parameter zu überprüfen ( Listing 1 ). Ruft man zur Installation eines virtuellen Systems das unter Listing 2 dargestellte Skript mit den drei Parametern VM-Namen, Host-Namen und IP-Adresse auf, so kennt der Spacewalk diese Parameter und verarbeitet sie als reguläre Variablen. Ein Kickstart-Profils kann dann auf diese Variablen zurückgreifen. Somit kommt das gleiche Setup-Skript für eine Vielzahl von Systemen zum Einsatz und auch das Kickstart-Profil lässt sich durch den Einsatz von Variablen für meherere Systeme verwenden.

%pre
for x in $( cat /proc/cmdline ); do
        case "$x" in
        *=*)
                eval $x;
        esac
done

virt-install \
--connect qemu+ssh://root@tiffy.tuxgeek.de/system \
--name $1 \
--ram 1024 \
--disk vol=kvmguests/172.16.0.1 \
--disk vol=kvmguests/172.16.0.2,perms=sh \
--network network:default \
--vnc \
--pxe \
--extra "hostnamen=$2 ip=$3"

Das Beispiel-Skript in Listing 2 setzt dabei zwei konfigurierte iSCSI-Server voraus. Diese können dann als Libvirt-Storage-Pools dienen. Ein Pool hält dabei das Root-Dateisystem der virtuellen Maschinen vor, der andere dient als Data-Pool. Die Konfiguration geschieht entweder über das grafische Tool Virt-Manager, ist aber auch problemlos auf der Kommandozeile möglich. Wie jedes andere Libvirt-Objekt kann der Administrator die neuen Storage-Pools mit Hilfe einer XML-Datei konfigurieren ( Listing 3 ). Dann aktiviert er sie mit »virsh pool-define kvmguests.xml« . Über den Aufruf »virsh pool-list --all« sollte der neue Pool nun sichtbar sein.

Ähnlich lassen sich ebenfalls neue Netzwerke als Libvirt-Objekte definieren. Um auch CPUs und Arbeitsspeicher von mehreren Maschinen verwenden zu können, sind diese entsprechend als KVM/Libvirt-basierte Hypervisoren zu konfiguriern. Für jeden Hypervisor könnte der Admin dann ein eigenes Skript erzeugen, das den passenden Hypervisor im »--connect« -Aufruf von »virt-install« angespricht. Die umfangreichen Hilfeseiten von Libvirt helfen hier weiter. Auch die Libvirt-Webseite [4] bietet eine sehr ausführliche Dokumentation an.

<pool type='iscsi'>
    <name>kvmguests</name>
    <source>
        <host name='grobi.tuxgeek.de'/>
        <device path='iqn.2010-08.fedora:fedora13:iscsi.kvmguests'/>
    </source>
    <target>
        <path>/dev/disk/by-path</path>
    </target>
</pool>

Wer anstatt mit »virt-manager« oder »virsh« lieber mit einem Webfrontend seine virtuellen Maschinen-Instanzen verwaltet, der sei an dieser Stelle auf die beiden Tools oVirt [8] und AbiCloud [9] verwiesen. Mit beiden Webfrontends ist das Einrichten von Ressource-Pools und virtuellen Maschinen in wenigen Mausklicks erledigt.