KVM Virtualisierung im Cluster unter Linux

Kernel-based Virtual Machine eine Einführung

KVM (Kernel-based Virtual Machine) ist eine vollständige Virtualisierung für Linux Betriebssystem auf x86 Hardware. Die Virtualisierung benötigt Intel VT auf Intel Prozessoren und AMD-V auf AMD Prozessoren. In der Basis besteht KVM aus dem kvm.ko Kernel Modul und entweder dem kvm-intel.ko oder kvm-amd.ko Modul. Die virtuellen Maschinen, sowohl mit Linux wie auch mit Windows Betriebssystemen können ohne Änderungen installiert und gestartet werden. Es werden nur die passenden Treiber für die virtuelle Hardware benötigt.
KVM ist Open-Source Software, die Module sind ab dem Kernel 2.6.20 enthalten. Neben den Modulen werden auch noch zusätzliche Komponenten im Userspace für die Administration und Verwaltung benötigt.

Warum KVM nutzen? Wer setzt die Linux Virtualisierung ein?

Die naheliegende Erklärung könnte der Preis sein. KVM ist Open-Source also kostenfrei erhältlich, das ist soweit auch richtig. Es gibt allerdings auch fertige Lösungen, die auf KVM basieren, dann aber kostenpflichtig sind. So zum Beispiel Proxmox, KVM zusammen mit ZFS, Ceph, einem Cluster und einer integrierten Bedienoberfläche.

Aber schauen wir uns KVM mal direkt an. Also die Software ist kostenfrei erhältlich, auch alle direkt benötigten Tools und Erweiterungen sind kostenfrei, weil Open-Source. Wenn man jetzt auf der anderen Seite VMware vSphere oder Microsoft Hyper-V betrachtet, dann werden dort nicht gerade gering Preise für Lizenzen und Wartung benötigt.

Aber ist KVM denn wirklich kostenfrei? Von den Lizenzen her ja, aber die Lösung muss installiert, konfiguriert und betrieben werden. Auch der Support muss in den meisten Fällen selbst übernommen werden. Die fertigen Lösungen sind dann ja wieder kostenpflichtig, aber mit Support.

Da sind wir auch schon beim "wer nutzt KVM". Planen Sie KVM professionell einzusetzen, so sollten Sie große Erfahrung mit Linux haben. Im Unternehmen sollte mehr als ein Mitarbeiter an dem Projekt arbeiten, nichts ist schlimmer in diesem Umfeld, als wenn der einzige Mitarbeiter für dieses Projekt das Unternehmen verlässt. Klar er hat viel Erfahrung mit KVM gesammelt und ist ein begehrter Wechselkandidat für andere Unternehmen. Und das sehen wir damit schon, kostenfrei ist KVM ja doch nicht. Man braucht Mitarbeiter die KVM installieren und betreiben, und die kosten natürlich Geld. Das muss man als Unternehmen genau betrachten, wie teurer wird die KVM Lösung für das Unternehmen und ist dann am Ende nicht vielleicht doch VMware kostengünstiger?

Um das ein wenig beurteilen zu können, haben wir Ihnen eine kurze Aufstellung einer möglichen KVM Lösung zusammengestellt. Es soll (und darf) nicht als 1 zu 1 Anleitung für den Bau einer KVM Lösung zu verstehen sein, sondern eher als grober Rahmen, wie man es machen könnte (aber nicht so machen muss). Oder man nimmt Proxmox und es ähnlich wie VMware oder Hyper-V zu betrachten.

Die Grundlagen zur KVM Lösung

Die KVM Software besteht aus Kernel-Modul und Userspace Komponenten, sie sind auf einem Server (= einer Server-Hardware) installiert. Auf dieser Hardware laufen dann viele verschiedene virtuelle Maschinen. Aber was passiert, wenn diese Hardware ausfallen sollte? Alle virtuellen Maschinen laufen dann nicht mehr und sind im Zweifelsfalle alle nicht mehr zugreifbar. Also muss wie bei anderen Lösungen auch, nicht nur ein Server die Aufgaben erfüllen können. Aber da kommen wir zu einem weiteren Problem: Greifen mehr als ein Server auf die gleichen Blockdevices zu, so wird das Filesystem zerstört, außer es wird ein Cluster-Filesystem genutzt.

Ok, einige Vorgaben haben wir also, KVM für die Virtualisierung, ein Cluster-Filesystem für den gemeinsamen Zugriff und ein Cluster für die Hochverfügbarkeit wäre wohl auch nicht schlecht.

Hardware für den Kernel Virtual Machine Cluster

Bei der Anzahl der Server ist also ein Server deutlich zu wenig, aber wie sieht es mit 2 aus? Ein Cluster mit einer geraden Anzahl von Nodes ist nicht sinnvoll, sollte bei 2 Nodes einer ausfallen, dann weiß der andere nicht, ob er der überlebende ist, oder ob er den anderen nur nicht sieht. Zum Schutz der Daten muss er also die Dienste einstellen. Also benötigen wir mindestens 3 Server, genau die Anzahl für unseren Test.

Dann benötigen wir noch ein Shared Storage, in diesem Beispiel per Fibre Channel angebunden, ob nun über einen Switch (SAN Storage) oder direkt anschlossen (als Direct Attached Storage) ist für diese Anwendung unwichtig. Wichtig ist nur, dass alle 3 Server auf das Storage zugreifen können. Das muss natürlich auch auf dem Storage so definiert werden, also die LUNs müssen von allen Servern zugreifbar sein und das lesend und schreibend.

Kurzer Hinweis: Warum nutzen wir nicht NFS oder SMB? Das würde die ganze Sache doch deutlich einfacher machen. Das ist absolut richtig, mit NFS sparen wir uns das Cluster-Filesystem und viele weitere Hürden auf unserem Weg. Aber in der Performance, gerade bei größeren und anspruchsvolleren Umgebungen kommt NFS schnell an die Grenze. Die Performance bricht ein und dann auf Fibre Channel oder iSCSI umzubauen (im laufenden Betrieb) wird extrem schwierig.

Basis Betriebssystem installieren und konfigurieren

Die technische Vorgabe für den KVM ist ein Linux Betriebssystem, also können wir die Distribution recht frei wählen. Wie schon erwähnt sollte man für dieses Projekt über Erfahrung mit Linux verfügen, also hat man auch eine "Lieblingsdistribution" und diese sollte man auch verwenden, wenn nicht etwas Wichtiges dagegen spricht. Nehmen wir in unserem Beispiel Debian in der aktuellen Version. Warum nun Debian? Ist ja nur ein Beispiel ...

Hinweis: Zum Zeitpunkt er Erstellung war die aktuelle Version von Debian Buster, aber auch mit neueren Version läuft die Installation ähnlich ab.

Wir nehmen also die Minimalversion von Debian, zusätzlich nur noch ssh installiert, alles andere folgt dann bei den einzelnen Punkten. Aber warum nur die Minimalversion? Je mehr Features auf dem KVM Knoten installiert sind, desto anfälliger wird das System für Security-Probleme, aber auch die Stabilität nimmt ab. Also keine GUI auf dem Server, auch wenn die GUI die Sache zum Teil deutlich einfacher machen würde.
Eine weitere Vorbereitung ist die Konfiguration der Netzwerke für das Admin-Netz. Hier muss jeweils eine fest IP-Adresse pro KVM Node vergeben werden.

Hinweis: Für eine produktive Umgebung sollte das Admin Netz redundant aufgebaut werden. Ansonsten kann durch den Ausfall eines LAN Switches der gesamte Cluster gestört werden.

Installation des Clusters (GFS2 / Pacemaker / Corosync)

Starten wir mit der Installation des Clusters auf den KVM Nodes. Diese Installation muss auf allen Cluster Nodes durchgeführt werden:

root@kvm1:~# apt-get install gfs2-utils \
                             fence-agents \
                             dlm-controld \
                             pacemaker \
                             rsync \
                             pcs \
                             multipath-tools \
                             lsscsi \
                             clvm

Zusätzlich zum eigentlichen Cluster und dem Cluster-Filesystem GFS2 installieren wir auch die multipath-tools mit, da der Shared Storage über mehr als einen Weg zugreifbar ist und den Cluster-Volume-Manager (clvm) gleich mit. Damit ist schon einmal die Software auf den Nodes vorhanden.

Die nachfolgende Konfiguration erfolgt nur auf einem der Nodes:

Als erstes passen wir die /etc/hosts entsprechend an, dass die IP-Adressen (Admin-Netz) der 3 KVM Nodes jeweils fest vergeben sind. Diese IP-Adressen müssen natürlich auf den einzelnen Nodes auch entsprechend konfiguriert worden sein. Diese Einstellungen sind eine wichtige Basis und sollten vorab kontrolliert werden.

root@kvm1:~# ssh-keygen -b 2048 -t rsa -C "root@kvm-nodes" -f ~/.ssh/id_rsa
root@kvm1:~# mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
root@kvm1:~# rsync -av /root/.ssh/* kvm2:/root/.ssh/
root@kvm1:~# rsync -av /root/.ssh/* kvm3:/root/.ssh/
root@kvm1:~# scp /etc/hosts kvm2:/etc/
root@kvm1:~# scp /etc/hosts kvm3:/etc/

Wichtiger Hinweis: Wir generieren hier Keys für den passwortfreien Zugriff zwischen der KVM Nodes. Dies ist stark vereinfacht, es werden sowohl die Public- wie auch die Private-Keys kopiert. Damit haben alle Nodes den gleichen Private-Key. Dies macht die Verwaltung in diesem Beispiel deutlich einfacher. Für die Produktion sollte man auf jedem Node (wie üblich) eigene Keys generieren und dann nur den Public-Key auf die anderen Nodes transportieren.

Warum kopieren wir die /etc/hosts zwischen den Nodes und nutzen nicht einfach DNS? Die Admin-IP-Adressen sind essentiell wichtig für die Funktion des Clusters. Hier sollte nicht auf einen Dienst zurückgegriffen werden, der evtl. auch mal ausfallen könnte (evtl. liegt der DNS Server auch als virtuelle Maschine auf dem KVM Cluster?).

Jetzt können wir den Cluster definieren, dies wird über das Dienstprogramm pcs durchgeführt:

root@kvm1:~# pcs cluster auth kvm1 kvm2 kvm3 --u hacluster --p cluster-passwort
root@kvm1:~# pcs cluster setup --name kvm_cluster kvm1 kvm2 kvm3

Der erste Befehlt legt den User hacluster mit dem Passwort cluster-passwort für unsere 3 KVM-Nodes an. Der zweite definiert dann den Cluster kvm_cluster auf den 3 Nodes.

Das war jetzt die Definition des Clusters, wir sind fertig. Na ja, so einfach ist es doch nicht, das war nur die Hülle des Clusters. War die Definition erfolgreich, dann kann jetzt die Cluster-Oberfläche auf dem Browser erreicht werden. Der Dienst läuft auf jedem der Nodes, also erreichbar über https://kvm1:2224. User und Passwort haben wir ja definiert, also hacluster mit dem Passwort cluster-passwort.

Kommen wir zu einem "unfreundlichen" Bestandteil des Clusters: STONITH, er macht was der Name verspricht, Shoot The Other Node In The Head. Also eine Kontrollinstanz im Cluster. Sollte ein Node nicht erreichbar sein, oder sich seltsam verhalten, so kann er von den anderen Nodes an "destruktiven" Tätigkeiten gehindert werden. Spaß beiseite, eine wichtige Funktion im Cluster, ohne diese könnte ein instabiler Node den gesamten Cluster mit allen Daten extrem gefährden.

root@kvm1:~# apt-get install fence-agents-ssh
root@kvm1:~# pcs -f stonith_cfg stonith create my_ssh-fence fence_ssh_soap \  
                 action=reboot \
                 pcmk_host_map="kvm1-cr:kvm1;kvm2-cr:kvm2;kvm3-cr:kvm3" \ 
                 pcmk_host_check=static-list \ 
                 pcmk_host_list="kvm1,kvm2,kvm3" \ 
                 power_wait=3 op monitor interval=90s
root@kvm1:~# pcs cluster cib-push stonith_cfg
root@kvm1:~# pcs property list --all | grep stonith
stonith-action: reboot
stonith-enabled: true
stonith-timeout: 60s
stonith-watchdog-timeout: (null)								 

Hinweis: Wir nutzen für diesen Test das Fence-Device ssh. Dies sollte nur für Tests genutzt werden, im produktiven Umfeld könnte man dann ein Fencing über SCSI nutzen.

Als erstes müssen wir den Fence Agent ssh erst einmal installieren, dann wird im nächsten Befehl über pcs die Cluster-Ressource angelegt, die den Fence Agent steuert. Über pcs cluster cib-push wird die Ressource "stonith_cfg" auf die anderen Nodes verteilt.
Über pcs property list kann die Konfiguration überprüft werden. Ist tatsächlich ein Stonith-Device vorhanden?

Installation und Konfiguration des Cluster Logical Volume Manager

Der Volume-Manager stellt logische Festplatten zur Verfügung. Auf diesen logischen Festplatten liegen später die Cluster Filesysteme (GFS2), der Volume Manager ist also quasi nur eine benötigte Zwischenschicht. Aber durchaus mit sinnvollen Funktionen, so kann eine LUN zum Beispiel in verschiedene Volumes aufgeteilt werden und die Volumes können auch im laufenden Betrieb vergrößert werden. Wichtig für den Cluster ist auch, dass die Volumes gezielt aktiviert und deaktiviert werden können.

root@kvm1:~# apt-get install lvm2-cluster
root@kvm1:~# lvmconf --enable-cluster

Diese beiden Befehle müssen wieder auf allen Nodes einzeln durchgeführt werden. Der erste Befehl installiert den Logical Volume Manager in der Cluster-Version. Der zweite Befehl aktiviert die Cluster Funktion im Volume Manager.

Die nachfolgenden Befehle dann wieder nur auf einem Node:

root@kvm1:~# pcs cluster cib dlm_cfg
root@kvm1:~# pcs -f dlm_cfg resource create dlm ocf:pacemaker:controld \
                 op monitor interval=120s on-fail=fence clone interleave=true ordered=true 
root@kvm1:~# pcs -f dlm_cfg resource create clvmd ocf:heartbeat:clvm \
                 op monitor interval=120s on-fail=fence clone interleave=true ordered=true
root@kvm1:~# pcs -f dlm_cfg constraint order start dlm-clone then clvmd-clone
root@kvm1:~# pcs -f dlm_cfg constraint colocation add clvmd-clone with dlm-clone

Die ersten beiden Befehle bauen den Distributed Lock Manager (DLM) als Cluster Ressource auf. Dieser sorgt für das Locking im Cluster, sperrt also schädliche gemeinsame Zugriffe über verschiedene Nodes hinweg. Dies wird unter anderem für den Volume Manager benötigt. Im dritten Befehl wird die Cluster Ressource für den Volume Manager (LVM) aufgebaut.
Was ist eigentlich genau diese Cluster Ressource? Der Volume Manager (nur mal als Beispiel) darf nicht mit dem Starten des Servers gestartet werden, sondern erst wenn der Cluster es wirklich benötigt. Also steuert der Cluster über die Ressourcen was und in welcher Menge im Cluster gestartet werden darf und auch wann. Und genau das kommt in den beiden nachfolgenden Befehlen: Dort wird die Reihenfolge des Starts festgelegt: Als erstes wird der dlm gestartet und erst dann der Cluster Volume Manager. Ist ja klar, wenn der Dienst für das Locking nicht läuft, dann sollte auch der Dienst, der das Locking benötigt, nicht vorher starten. Also im Prinzip das Gleiche wie die Start-Reihenfolge beim Booten des Betriebssystem (z.B. unter /etc/rc1.d usw.).

Das Cluster Filesystem GFS2 braucht ein Quorum im Cluster, dies bedeutet, dass eine gewisse Menge an Nodes (gleich die Mehrheit, in unserem Beispiel 2 Stück) aktiv sein müssen, damit dieser Dienst zur Verfügung gestellt werden kann (Schutz unter anderem vor Split-Brain im Cluster).

root@kvm1:~# pcs -f dlm_cfg property set no-quorum-policy=freeze
root@kvm1:~# pcs -f dlm_cfg constraint
Location Constraints:
Ordering Constraints:
  start dlm-clone then start clvmd-clone (kind:Mandatory)
Colocation Constraints:
  clvmd-clone with dlm-clone (score:INFINITY)
Ticket Constraints:
root@kvm1:~# pcs -f dlm_cfg resource show
Clone Set: dlm-clone [dlm]
     Stopped: [ kvm1 kvm2 kvm3 ]
Clone Set: clvmd-clone [clvmd]
     Stopped: [ kvm1 kvm2 kvm3 ]
root@kvm1:~# pcs cluster cib-push dlm_cfg

Der erste Befehl setzt die Quorum-Policy für das GFS2, die beiden weiteren Befehle kontrollieren, ob die Ressourcen sauber konfiguriert sind. Wichtig ist dabei die Startreihenfolge und dass die Ressourcen jetzt noch gestoppt sind. Der letzte Befehl aktiviert die Ressourcen auf allen Nodes im Cluster.

Damit haben wir jetzt eine Volume-Manager mit Kontrolle (DLM und Quorum) im Cluster laufen (bzw. auf jedem Node).

Installation des Cluster Filesystems (GFS2)

Die GFS Konfiguration wird wieder nur auf einem Node durchgeführt, als erstes muss geprüft werden, welche LUN (bzw. welches Device) genutzt werden soll. In unserem Falle kommen die LUNs von einem Fibre Channel Storage über redundante Pfade, also ist dies auf jeden Fall ein Multipath-Device. Dies sind die dm-Devices. Die Zuordnung zwischen physikalischer LUN und Mutlipath Device lässt sich mit multipath -ll ermitteln. Die Devices befinden sich dann unter /dev/mapper:

root@kvm1:~# ls -l /dev/mapper
lrwxrwxrwx 1 root root       7 Dez 28 11:13 3600601602f303b000a95084c8a0ae911 -> ../dm-0
root@kvm1:~# pvcreate /dev/mapper/3600601602f303b000a95084c8a0ae911
root@kvm1:~# vgcreate --autobackup=y --clustered=y vg_cluster /dev/mapper/3600601602f303b000a95084c8a0ae911
root@kvm1:~# lvcreate --size 512M --name lv_storage vg_cluster

Mit dem ersten Befehl finden wir unser Device dm-0, mit dem pvcreate nutzen wir dieses Device für den Volume Manager. Mit vgcreate wird dann eine Volume Group mit dem Namen vg_cluster auf diesem Device angelegt (bzw. dieses Device wird für die Volume Group genutzt). Auf diese Volumegroup wird dann ein Logical Volume mit dem Namen lv_storage definiert. Auf diesem Volume legen wir dann später das GFS2 Filesystem an.

root@kvm1:~# mkfs.gfs2 -j3 -J32 -t kvm_cluster:gfs2_storage -p lock_dlm /dev/vg_cluster/lv_storage
root@kvm1:~# mkdir -p /kvm/storage 
root@kvm2:~# mkdir -p /kvm/storage
root@kvm3:~# mkdir -p /kvm/storage
root@kvm1:~# pcs resource create gfs2_res01 Filesystem device="/dev/vg_cluster/lv_storage" \
                 directory="/kvm/storage" fstype="gfs2" \ 
                 options="noatime,nodiratime,rw" \
                 op monitor interval=50s on-fail=fence clone interleave=true
root@kvm1:~# pcs constraint order start clvmd-clone then gfs2_res01-clone
root@kvm1:~# pcs constraint colocation add gfs2_res01-clone with clvmd-clone
root@kvm1:~# mount|grep gfs2

Der erste Befehl legt das GFS2 Filesystem auf dem lv_storage an. Hierzu werden 3 Journale mit jeweils 32 MB angelegt (-j -J). Wichtig ist das Anlegen des Mountpoints auf allen 3 Nodes. Ansonsten wird der mount nicht klappen, den der Cluster beim Starten der Ressource durchführt. Das pcs resource create legt dann die Ressource für das GFS2 Filesystem an. Auch das Filesystem muss natürlich durch den Cluster gemountet werden, auf keinen Fall durch den Boot des Betriebssystems. Auch bei GFS2 ist die Start-Reihenfolge wichtig. Als erstes muss der Volume Manager gestartet werden, erst dann das GFS2. Anders herum wird es nicht klappen, woher soll das GFS2 denn sonst das Logical Volume nehmen ...
Der letzte Befehl kontrolliert dann, ob das Filesystem wirklich auf jedem Node gemountet ist.

Wie wird denn jetzt ein umount des GFS Filesystem durchgeführt? Auf keinen Fall mit einem umount auf der Command-Line. Weil jeder Ressource im Cluster darf nur durch den Cluster selbst gestartet oder gestoppt werden, also:

root@kvm1:~# pcs resource disable --wait=5 gfs2_res01
root@kvm1:~# fsck.gfs2 /dev/vg_cluster/lv_storage
root@kvm1:~# pcs resource enable gfs2_res01

Der erste Befehlt stoppt das GFS2 Filesystem (der umount), dann kann zum Beispiel ein Filesystemcheck durchgeführt werden. Der letzte Befehl startet dann das GFS2 wieder (= der mount).

Kann das GFS denn im laufenden Betrieb vergrößert werden? Ja das ist kein Problem, auch dank des Volume Managers ist es recht einfach:

root@kvm1:~# lvextend --size +100G /dev/vg_cluster/lv_storage
root@kvm1:~# gfs2_grow /dev/vg_cluster/lv_storage

KVM Installation

Nach den ganzen Vorbereitungen können wir jetzt den KVM an sich installieren, das Filesystem für die virtuellen Maschinen ist ja angelegt und auf allen Nodes gemountet. Die Installation des KVM muss wieder auf allen Nodes erfolgen:

root@kvm1:~# apt-get install qemu-kvm \ 
                             libvirt-clients \
                             libvirt-daemon-system \
                             bridge-utils \
                             libguestfs-tools \
                             genisoimage \
                             virtinst \
                             libosinfo-bin
root@kvm1:~# adduser admin libvirt
root@kvm1:~# adduser admin libvirt-qemu

root@kvm1:~# virsh --connect qemu:///system
root@kvm1:~# virsh --connect qemu:///system command

Die Installation an sich war jetzt ganz einfach und übersichtlich. Der User admin (der muss natürlich vorher erst mal angelegt werden) kann zur Administration der virtuellen Maschinen genutzt werden. Statt dem User admin können weitere User oder andere User angelegt werden.
Das virsh-Kommando ist eines der Basis-Programme vom KVM, mit diesem Befehl kann die Installation überprüft werden, der connect verbindet sich zum KVM Daemon auf dem Host.

Virtuelles Netzwerk - Installation

Damit die virtuellen Maschinen auch auf das Netzwerk zugreifen können, muss als erstes eine Bridge angelegt werden. Eine Bridge ist ähnlich wie ein virtueller LAN-Switch zu sehen, die VMs verbinden sich mit dieser Bridge und kommen dann weiter ins LAN. Diese Bridge muss unter /etc/networks/interfaces angelegt werden:

auto br0 
iface br0 inet static 
	address 10.0.1.52 
	broadcast 10.0.1.255 
	netmask 255.255.255.0 
	gateway 10.0.1.210 
	bridge_ports eno2 
	bridge_stp off 
	bridge_waitport 0 
	bridge_fd 0 

Anmerkung: Die Netzwerkadressen müssen entsprechend der eigenen Umgebung angepasst werden. Dieses Bridge-Device muss danach dem KVM bekannt gemacht werden. Dazu wird eine xml Datei mit der entsprechenden Konfiguration angelegt:

root@kvm1:~# vi /etc/bridged.xml
<network> 
	<name>br0</name> 
	<forward mode="bridge"/> 
	<bridge name="br0"/> 
</network>

root@kvm1:~# virsh net-define --file /etc/bridged.xml
root@kvm1:~# virsh net-autostart br0
root@kvm1:~# virsh net-start br0

Das xml File definiert unsere einfache Bridge, der erste Befehl übernimmt diese Definition in den KVM, der zweite Befehl richtet einen Autostart für diese Bridge ein und der dritte Befehl starte die Bridge jetzt aktuell. Diese Konfiguration muss auf jedem der KVM Nodes durchgeführt werden.

Damit ist die Konfiguration des KVM abgeschlossen, die erste virtuelle Maschine kann eingerichtet werden.

KVM - die erste virtuelle Maschine einrichten

Da die KVM Nodes keine GUI installiert haben, müssen wir auch die virtuellen Maschinen über die Command Line installieren. Dafür gibt es verschiedene Möglichkeiten, wir nehmen in diesem Beispiel virt-install aus dem KVM Paket:

admin@kvm1:~# virt-install --virt-type=kvm --name <name> \
                           --ram 2048 --vcpus=2 --os-variant=debian9 --kvm \ 
                           --cdrom=/data/cdrom/debian9.iso \
                           --network=bridge=br0,model=virtio \
                           --graphics vnc \
                           --disk-path=/kvm/storage/images/<name>/<name>
                           qcow2,size=40,bus=virtio,format=qcow2
admin@kvm1:~# virsh vncdisplay <name>

Mit dem Commandline Befehl virt-install legen wir eine neue virtuelle Maschine an. Die meisten Parameter sind selbsterklärend, wie zum Beispiel ram oder vcpus. Interessant ist der Parameter graphics. Er definiert die Schnittstelle und das Protokoll für die Console der virtuellen Maschine. Wollen wir in diesem Beispiel die virtuelle Maschine mit einer GUI (z.B. Gnome) anlegen, so müssen wir ja irgendwie auf die grafische Anzeige kommen. Dafür kann KVM das VNC-Protokoll nutzen. Die grafische Konsole wird also auf einem VNC Port zur Verfügung gestellt und diesen Port ermittelt man mit dem unteren Befehl.
Hinweis: KVM stellt die Konsole ohne weitere Parameter nur lokal zur Verfügung. Dies bedeutet der jeweilige VNC Port ist nur über die lokale Schnittstelle des KVM Hosts erreichbar. Warum wird das gemacht? Das VNC Protokoll ist nicht gerade so richtig sicher, daher geht man den Umweg über einen ssh Tunnel vom Admin-PC auf den jeweiligen KVM Host.

admin@pc:~# ssh admin@kvm1 --L 5901:127.0.0.1:5901

Damit wir der Port 5901 von der lokalen Schnittstelle des KVM Hosts auf den Port 5901 auf den Admin PC getunnelt. Dort kann dann ein VNC Viewer gestartet werden und hat Zugriff auf die Konsole der virtuellen Maschine. Die Konsole ist mit ssh User und ssh Passwort geschützt und auch noch per ssh verschlüsselt, also der Transport ist verschlüsselt.
Es ist natürlich auch möglich, diesen Tunnel auf einen Windows PC einzurichten. Dafür kann zum Beispiel Putty genutzt werden.

Agiert man in einem sicheren Admin Netz, dann kann die Display-Freigabe auch auf andere Netzwerke (nicht localhost) gelegt werden, zum Beispiel mit --graphics vnc,listen=0.0.0.0 auf alle Netzwerkkarten des KVM Hosts. Das müsste man entsprechend auf die Admin-Netze einschränken, es wird deutlich einfacher, aber auch unsicherer.

Einige wichtige KVM Befehle

Der grundlegende Befehl ist virsh für die Bedienung der virtuellen Maschinen, hier keine kleine unvollständige Aufstellung:

admin@kvm1:~# virsh list --all
--> Listet alle virtuellen Maschinen auf (ein- und ausgeschaltet)
admin@kvm1:~# virsh console <name>
--> Ruft die Text-Console der virtuellen Maschine auf.
admin@kvm1:~# virsh shutdown <name>
--> Fährt die virtuelle Maschine herunter.
admin@kvm1:~# virsh start <name>
--> Startet die virtuelle Maschine.
admin@kvm1:~# virsh reboot <name>
--> Rebootet die virtuelle Maschine.
admin@kvm1:~# virsh reset <name>
--> Hartes Ausschalten der virtuellen Maschine, Power off
admin@kvm1:~# virsh undefine <name> 
--> Registrierung der virtuellen Maschine aufheben
admin@kvm1:~# virsh migrate --live <name> qemu+ssh://<node>/system
--> Live Migration der virtuellen Maschine auf einen neuen VKM Node

Interessant ist das virsh migrate. Damit können virtuelle Maschine im laufenden Betrieb auf einen anderen KVM Node verschoben werden. Dafür muss dann aber der zweite Node auch Zugriff auf die Daten (Filesysteme) haben und dafür haben wir ja den Cluster mit dem Cluster-Filesystem eingerichtet. Eine wichtige Funktion für den produktiven Betrieb einer KVM Umgebung haben wir also schon geschaffen.

Virtuelle Maschinen im HA Cluster

Wir haben ja einen Cluster eingerichtet, am Anfang eigentlich nur für das Cluster-Filesystem, aber wenn wir schon einen Cluster haben, dann können wir doch auch die virtuellen Maschinen hochverfügbar machen. Das ist in diesem Stadium eigentlich recht einfach.
Aber eines ist zu beachten: Wenn wir die virtuelle Maschine unter Kontrolle des Clusters stellen, dann dürfen wir die Maschine nicht mehr außerhalb des Clusters bearbeiten. Was bedeutet dies? Wenn der Cluster die Funktion der virtuellen Maschine überwacht und wir fahren die Maschine einfach so herunter (ohne das der Cluster von unserem Vorhaben informiert wurde), dann muss der Cluster von einer Störung ausgehen und wird die virtuelle Maschine einfach wieder starten.

Schauen wir uns das Vorgehen einmal an:

admin@kvm1:~# virsh dumpxml <name> > /etc/pacemaker/<name>.xml
admin@kvm1:~# scp /etc/pacemaker/<name>.xml kvm2:/etc/pacemaker/
admin@kvm1:~# scp /etc/pacemaker/<name>.xml kvm3:/etc/pacemaker/
admin@kvm1:~# pcs resource create vm-<name> 
                           VirtualDomain 
                           config=/etc/pacemaker/<name>.xml 
                           migration_transport=ssh 
                           hyperviror=qemu:///system 
                           meta 
                           allow-migration=true
admin@kvm1:~# pcs resource move <name> kvm2

Mit dem ersten Befehl, dem virsh dumpxml wird die Konfiguration der virtuellen Maschine in ein xml File geschrieben. Dieses xml File nutzt der Cluster für die weitere Steuerung der virtuellen Maschine. Da die virtuelle Maschine auf allen Cluster Nodes laufen können muss, müssen die Konfigurationen auch auf allen Nodes vorhanden sein. Als Alternative zum Kopieren der xml Files können diese auch auf dem Cluster-Filesystem hinterlegt werden.
Mit dem Befehl pcs wird dann wieder eine Ressource angelegt, diesmal eben die virtuelle Maschine. Die Ressource kann zum Beispiel auch über die Weboberfläche des Clusters (https://kvm1:2224) verändert werden.
Der untere pcs resource move Befehl ist dann die Migration der virtuellen Maschine, das Live Migrate. Man muss im Cluster also nicht auf Hot Migrate verzichten, es muss nur über den Cluster gesteuert werden. Genau so wird dann die Ressource auch gestoppt oder gestartet.

Hinweis: Was fehlt dieser Ressource jetzt noch? Na klar die Abhängigkeit, wenn das GFS2 nicht da ist, dann kann die VM auch nicht gestartet werden. Da sollte man noch einbauen, wenn man einen Autostart der VMs einplanen möchte. Werden die VMs aber immer nur per Hand gestartet, dann kann man dies auch weglassen.

Verbesserungen im KVM Cluster

Dieses Beispiel soll nur die Funktion eines KVM Cluster verdeutlichen, ab jetzt wird die Sache erst interessant. Wo liegen die Probleme bei diesem Cluster? Laufen jetzt einige virtuelle Maschinen, so ist es schwierig herauszufinden auf welchen KVM Hosts laufen sie eigentlich. Und wenn man mal schnell an die Konsole der virtuellen Maschine ran muss, dann müsste man sich erst per ssh an allen 3 Nodes anmelden, mit virsh vncdisplay den Port herausbekommen und dann per VNC Viewer auf die Konsole zu kommen. Alles sehr umständlich und kompliziert und in der Praxis nicht wirklich tauglich.
Es gibt einige Tools zur Administration, die haben alle mehr oder weniger Nachteile. Eventuell passt da ja ein fertiges Produkt. Wenn nicht, dann ist es nicht so schwierig, aber dennoch aufwendig, eine eigene Lösung zu bauen. Man benötigt nur einen zentralen Webserver, der alle Informationen sammelt (am Besten in einer Datenbank) und dann nutzbar macht. Also zum Beispiel mit virsh vncdisplay alle laufenden VMs mit den dazugehörigen Ports an den zentralen Server melden und dort als "klickbare" Liste anzeigen lassen. Ohne grafische Aufbereitung ist das schnell gemacht. Auch weiß man dann genau, welche virtuelle Maschine auf welchem KVM Host läuft. Die Cluster Console lässt sich auch einfach einbinden, da ist die grafische Aufbereitung sogar schon fertig.
Dann kann man auf dem zentralen Host auch noch fertige Auswertetools (wie zum Beispiel Nagios) nutzen und eine "quick and dirty" Version ist schnell vorhanden.

Aber eines sollte allen klar sein: Die gesamte Lösung besteht aus Open Source Komponenten, einen effektiven Support von außen wird man da kaum bekommen. Wichtig ist dabei das eigene Know-how in der Lösung. Und das sollte für alle die so eine Lösung planen als Entscheidung dienen: Kann der Support und die Installation langfristig aus eigenen Ressourcen erfolgen und ist das eigene Know-how vorhanden.

Eine flexiblere und individuellere Lösung kann man nicht finden.