Storage. Backup. Virtualisierung.
KVM im Cluster, Virtualisierung unter Linux · Version 1.6 · © Stor IT Back 2026
Kurz erklärt: Ein KVM-Cluster verbindet mehrere Linux-Server zu einer gemeinsamen Virtualisierungsumgebung. KVM stellt die hardwaregestützte Virtualisierung im Linux-Kernel bereit, QEMU bildet die virtuelle Hardware ab und Libvirt übernimmt die Verwaltung der virtuellen Maschinen. Pacemaker und Corosync können Hochverfügbarkeit, Quorum und Ressourcensteuerung übernehmen. Bei blockbasiertem Shared Storage lässt sich GFS2 als Cluster-Dateisystem einsetzen, damit mehrere Hosts kontrolliert auf dieselben VM-Daten zugreifen können.
Diese Seite zeigt einen möglichen technischen Aufbau mit Debian 13 „Trixie“, KVM/QEMU, Libvirt, Pacemaker, Corosync, DLM, lvmlockd, GFS2 und gemeinsamem Fibre-Channel-Storage. Sie ist als Praxisbeispiel und technische Orientierung gedacht, nicht als 1:1-Bauanleitung für jede produktive Umgebung. Hardware, Fencing, Netzwerk, Storage und Sicherheitskonzept müssen immer an die konkrete Infrastruktur angepasst werden.
KVM steht für Kernel-based Virtual Machine und ist die Virtualisierungstechnik des Linux-Kernels. Auf x86-Systemen nutzt KVM die Hardware-Virtualisierung der Prozessoren, also Intel VT-x beziehungsweise AMD-V. Im Kernel kommen dazu die KVM-Module zum Einsatz; QEMU stellt die virtuelle Hardware wie CPU-Modell, Controller, Netzwerkkarten und virtuelle Datenträger bereit.
Für die Administration wird in der Praxis häufig Libvirt eingesetzt. Libvirt abstrahiert
QEMU/KVM und stellt mit virsh eine Kommandozeilenverwaltung sowie Schnittstellen für weitere Management-Werkzeuge bereit.
Auf einem KVM-Host können dadurch unveränderte Linux- und Windows-Gastsysteme betrieben werden.
Für gute Performance sollten in den Gästen paravirtualisierte VirtIO-Treiber für Storage und Netzwerk verwendet werden.
KVM ist Open Source und seit vielen Jahren Bestandteil des Linux-Kernels. Die Virtualisierung selbst ist damit eng in Linux integriert; für eine komplette Unternehmensplattform werden jedoch zusätzliche Komponenten für Management, Storage, Netzwerk, Backup, Monitoring und Hochverfügbarkeit benötigt.
Ein wichtiger Vorteil von KVM ist die offene Architektur. KVM, QEMU und viele Verwaltungswerkzeuge sind als Open-Source-Software verfügbar. Dadurch entstehen zunächst keine klassischen Hypervisor-Lizenzkosten. Das bedeutet jedoch nicht, dass eine KVM-Plattform automatisch kostenlos betrieben werden kann: Planung, Installation, Betrieb, Updates, Monitoring, Backup und Fehleranalyse benötigen Zeit und qualifiziertes Personal.
Wer KVM direkt und ohne fertige Plattform einsetzt, sollte deshalb über fundierte Linux-, Netzwerk-, Storage- und Cluster-Kenntnisse verfügen. Für den professionellen Betrieb ist es sinnvoll, das Wissen auf mehrere Administratoren zu verteilen und Installation sowie Betriebsprozesse sauber zu dokumentieren.
Alternativ kann eine fertige Virtualisierungsplattform auf Basis von KVM eingesetzt werden. Proxmox VE kombiniert beispielsweise QEMU/KVM, LXC, Storage-Funktionen, Cluster, Hochverfügbarkeit und eine integrierte Weboberfläche. Damit bleibt die KVM-Technik erhalten, während viele Verwaltungsaufgaben bereits in einer fertigen Plattform zusammengeführt sind.
Die wirtschaftliche Entscheidung sollte deshalb nicht nur die Lizenzkosten betrachten. Entscheidend sind die Gesamtkosten aus Hardware, Storage, Administration, Know-how, Support, Backup, Wartung und Ausfallrisiko. Für manche Unternehmen ist eine selbst aufgebaute KVM-Lösung optimal, für andere ist eine integrierte Plattform wie Proxmox VE wirtschaftlicher.
Ein einzelner KVM-Server kann viele virtuelle Maschinen betreiben, bleibt aber zunächst ein einzelner Ausfallpunkt. Fällt dieser Host aus, stehen die darauf laufenden VMs nicht mehr zur Verfügung. Für höhere Verfügbarkeit werden daher mehrere KVM-Nodes zu einem Cluster zusammengefasst.
Bei dem hier beschriebenen Aufbau greifen mehrere Nodes auf denselben blockbasierten Storage zu. Ein normales lokales Dateisystem wie ext4 oder XFS darf nicht gleichzeitig von mehreren Hosts auf demselben Blockdevice eingehängt werden. Für einen parallelen Zugriff wird deshalb ein Cluster-Dateisystem wie GFS2 benötigt. Der Distributed Lock Manager (DLM) koordiniert dabei Sperren zwischen den Nodes.
Die wichtigsten Bausteine dieses Beispiels sind:
Andere Architekturen sind ebenfalls möglich. NFS benötigt beispielsweise kein GFS2 auf den KVM-Hosts, und verteilte Storage-Systeme wie Ceph lösen den gemeinsamen Datenzugriff auf andere Weise. Die folgende Konfiguration zeigt bewusst einen klassischen Aufbau mit blockbasiertem Shared Storage.
Für einen produktiven Cluster sind mindestens zwei KVM-Nodes erforderlich. Moderne Corosync-/Pacemaker-Umgebungen können auch als Zwei-Node-Cluster betrieben werden. Dabei ist ein korrektes Fencing besonders wichtig, damit bei einer Kommunikationsstörung eindeutig feststeht, welcher Node weiterarbeiten darf. Drei Nodes sind häufig einfacher zu planen, weil eine echte Stimmenmehrheit im Cluster vorhanden ist und Wartungsarbeiten flexibler durchgeführt werden können.
Für dieses Beispiel verwenden wir drei Server. Die Nodes sollten möglichst vergleichbare CPU-Generationen und CPU-Features besitzen, damit Live-Migrationen nicht an inkompatiblen Prozessorfunktionen scheitern.
Zusätzlich benötigen wir Shared Storage. In diesem Beispiel ist der Storage per Fibre Channel redundant angebunden. Entscheidend ist, dass alle KVM-Nodes auf die benötigten LUNs lesend und schreibend zugreifen können. Bei mehreren Pfaden zum Storage sollte Device Mapper Multipath eingesetzt werden.
Warum nicht einfach NFS? NFS kann für Virtualisierung sehr gut geeignet sein und vereinfacht den Aufbau, weil kein blockbasiertes Cluster-Dateisystem benötigt wird. Ob NFS, iSCSI, Fibre Channel oder ein verteiltes Storage-System die bessere Wahl ist, hängt von Latenz, Durchsatz, Redundanz, Skalierung, Betriebsmodell und vorhandener Infrastruktur ab. Wir verwenden hier Fibre Channel, um den Aufbau mit Multipath, Shared LVM, DLM und GFS2 zu zeigen.
Für produktive Systeme sollten außerdem Management-, Cluster-, VM- und Storage-Verkehr logisch oder physisch getrennt und redundant ausgelegt werden. Ein einzelner Switch, eine einzelne NIC oder ein einzelner Storage-Pfad würde sonst einen unnötigen Single Point of Failure darstellen.
KVM ist Bestandteil von Linux, deshalb kann die Distribution grundsätzlich frei gewählt werden. Für einen produktiven Cluster sollte eine stabile Distribution verwendet werden, mit der das Administratorenteam gut vertraut ist. In diesem Beispiel nutzen wir Debian 13 „Trixie“.
Wir installieren eine möglichst schlanke Debian-Serverbasis ohne grafische Oberfläche. Weniger zusätzlich installierte Software reduziert die Zahl unnötiger Dienste, erleichtert Updates und verkleinert die Angriffsfläche. Für die Administration genügt zunächst SSH.
Jeder KVM-Node erhält eine feste Management-IP-Adresse und einen eindeutigen Hostnamen.
DNS kann eingesetzt werden, für die Cluster-Kommunikation sollten Namensauflösung und Adressierung aber so ausgelegt sein,
dass sie nicht von Diensten abhängen, die selbst als VM im gleichen Cluster laufen. Eine gepflegte /etc/hosts
kann deshalb für ein kleines Test-Setup sinnvoll sein.
Hinweis: In einer produktiven Umgebung sollten Management- und Cluster-Netz redundant ausgelegt werden. Corosync kann bei passendem Design mehrere Links verwenden. Auch die Zeit-Synchronisation aller Nodes muss zuverlässig funktionieren.
Auf allen KVM-Nodes installieren wir die benötigten Cluster-, Storage- und Verwaltungswerkzeuge. Die Paketnamen beziehen sich auf Debian 13:
root@kvm1:~# apt-get update
root@kvm1:~# apt-get install pacemaker corosync pcs \
resource-agents fence-agents \
gfs2-utils dlm-controld lvm2-lockd \
multipath-tools lsscsi rsync
pcs dient zur Konfiguration von Pacemaker und Corosync. resource-agents stellt OCF-Ressourcen bereit, fence-agents
enthält Fencing-Agenten, dlm-controld den Distributed Lock Manager und lvm2-lockd den für Shared LVM benötigten Dienst lvmlockd.
Danach wird auf allen Nodes pcsd aktiviert und für den Benutzer hacluster ein Passwort gesetzt:
root@kvm1:~# systemctl enable --now pcsd root@kvm1:~# passwd hacluster
Die Hostnamen und Management-Adressen müssen auf allen Nodes korrekt auflösbar sein. Für dieses Beispiel verwenden wir die Namen kvm1, kvm2 und kvm3. Die Authentifizierung und Cluster-Erstellung erfolgen anschließend von einem Node aus:
root@kvm1:~# pcs host auth kvm1 kvm2 kvm3 Username: hacluster Password: root@kvm1:~# pcs cluster setup kvm_cluster kvm1 kvm2 kvm3 root@kvm1:~# pcs cluster enable --all root@kvm1:~# pcs cluster start --all root@kvm1:~# pcs status
Damit ist der Cluster-Grundaufbau vorhanden. Die Weboberfläche von pcsd ist standardmäßig über TCP-Port 2224 erreichbar, sofern Firewall und Netzkonzept dies zulassen.
Für einen produktiven HA-Cluster ist Fencing unverzichtbar. Ein Node, dessen Zustand nicht mehr eindeutig beurteilt werden kann, muss zuverlässig vom Zugriff auf gemeinsam genutzte Ressourcen ausgeschlossen werden. Andernfalls drohen Split Brain, parallele Schreibzugriffe und im schlimmsten Fall Datenverlust.
Geeignete Fence-Mechanismen nutzen möglichst eine vom Betriebssystem des betroffenen Nodes unabhängige Steuerung, zum Beispiel IPMI, iDRAC, iLO, einen PDU-Agenten oder Storage-basiertes Fencing. Ein einfaches SSH-Fencing ist nur für Laborzwecke sinnvoll, weil es gerade dann versagen kann, wenn Betriebssystem oder Netzwerkstack des Hosts gestört sind.
Welche Agents auf dem System verfügbar sind, lässt sich beispielsweise so prüfen:
root@kvm1:~# pcs stonith list root@kvm1:~# pcs stonith describe fence_ipmilan
Ein konkretes Fencing-Beispiel muss immer zur eingesetzten Hardware passen. Zugangsdaten und Management-Netz sollten getrennt vom normalen VM-Verkehr abgesichert werden.
Frühere Cluster-Installationen verwendeten häufig clvmd.
Bei aktuellen LVM2-Versionen wird für gemeinsam genutzte Volume Groups lvmlockd eingesetzt.
lvmlockd koordiniert den Zugriff auf Shared LVM und kann DLM oder sanlock als Lock Manager verwenden.
Da in unserem Beispiel Corosync und DLM ohnehin für GFS2 benötigt werden, verwenden wir DLM.
Auf allen Nodes wird in /etc/lvm/lvm.conf die Nutzung von lvmlockd aktiviert:
use_lvmlockd = 1
DLM und lvmlockd sollen durch den Cluster gesteuert werden. Ein mögliches Grundschema mit pcs sieht so aus:
root@kvm1:~# pcs resource create dlm ocf:pacemaker:controld \
op monitor interval=30s
root@kvm1:~# pcs resource clone dlm dlm-clone meta interleave=true
root@kvm1:~# pcs resource create lvmlockd ocf:heartbeat:lvmlockd \
op monitor interval=30s
root@kvm1:~# pcs resource clone lvmlockd lvmlockd-clone meta interleave=true
root@kvm1:~# pcs constraint order start dlm-clone then lvmlockd-clone
root@kvm1:~# pcs constraint colocation add lvmlockd-clone with dlm-clone
Der DLM stellt die verteilten Locks bereit; lvmlockd nutzt diese Locks für LVM. Bei Shared Volume Groups müssen Start, Stop und Aktivierung über das Cluster-Konzept abgestimmt werden. Die genaue Ressourcenstruktur kann sich je nach eingesetzter Pacemaker-/pcs-Version und Storage-Design unterscheiden und sollte vor einem Produktiveinsatz in einer Testumgebung geprüft werden.
Ein Quorum ist für gemeinsam genutzte Ressourcen besonders wichtig. Bei Verlust des Quorums darf der Cluster keine Situation zulassen,
in der zwei voneinander getrennte Partitionen gleichzeitig schreibend auf dieselben Daten zugreifen.
Zunächst muss das gemeinsame Storage-Device eindeutig ermittelt werden. Bei redundant angebundenem Fibre-Channel- oder
iSCSI-Storage sollte dafür das Multipath-Device unter /dev/mapper verwendet werden und nicht einer der einzelnen physischen Pfade.
root@kvm1:~# multipath -ll root@kvm1:~# ls -l /dev/mapper/
Im Beispiel verwenden wir die Multipath-LUN /dev/mapper/3600601602f303b000a95084c8a0ae911.
Darauf wird eine Shared Volume Group und anschließend ein Logical Volume angelegt:
root@kvm1:~# pvcreate /dev/mapper/3600601602f303b000a95084c8a0ae911
root@kvm1:~# vgcreate --shared vg_cluster \
/dev/mapper/3600601602f303b000a95084c8a0ae911
root@kvm1:~# vgchange --lockstart vg_cluster
root@kvm1:~# lvcreate --size 512G --name lv_storage vg_cluster
vgcreate --shared kennzeichnet die Volume Group als gemeinsam genutzt.
Bei DLM speichert LVM dabei auch die Cluster-Zuordnung. Die Größe von 512 GByte ist nur ein Beispiel
und muss natürlich an die vorhandene LUN und die geplanten virtuellen Maschinen angepasst werden.
Nun wird das GFS2-Dateisystem erstellt. Die Anzahl der Journale muss mindestens zur Zahl der Hosts passen, die das Dateisystem gleichzeitig mounten sollen:
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
Das Dateisystem sollte als Cluster-Ressource verwaltet werden, damit Startreihenfolge und Abhängigkeiten kontrolliert sind. Das folgende Beispiel zeigt das Prinzip:
root@kvm1:~# pcs resource create gfs2_storage ocf:heartbeat:Filesystem \
device="/dev/vg_cluster/lv_storage" \
directory="/kvm/storage" fstype="gfs2" \
options="noatime" \
op monitor interval=30s
root@kvm1:~# pcs resource clone gfs2_storage gfs2_storage-clone \
meta interleave=true
root@kvm1:~# pcs constraint order start lvmlockd-clone then gfs2_storage-clone
root@kvm1:~# pcs constraint colocation add gfs2_storage-clone with lvmlockd-clone
Ein Cluster-Dateisystem, das vom Cluster verwaltet wird, sollte nicht unabhängig mit mount, umount
oder per statischem Boot-Eintrag gestartet und gestoppt werden. Für Wartungsarbeiten wird die Ressource über Pacemaker deaktiviert und danach wieder aktiviert.
root@kvm1:~# pcs resource disable gfs2_storage --wait=60 root@kvm1:~# fsck.gfs2 /dev/vg_cluster/lv_storage root@kvm1:~# pcs resource enable gfs2_storage
Auch eine Erweiterung ist grundsätzlich online möglich. Zuerst wird das Logical Volume vergrößert und anschließend das GFS2-Dateisystem:
root@kvm1:~# lvextend --size +100G /dev/vg_cluster/lv_storage root@kvm1:~# gfs2_grow /kvm/storage
Vor Änderungen am Storage sollten selbstverständlich ein aktuelles Backup, ein getesteter Recovery-Weg und eine dokumentierte Rückfallstrategie vorhanden sein.
Nach Cluster und Storage installieren wir die eigentliche Virtualisierung auf allen KVM-Nodes. Unter Debian 13 stellt das Paket qemu-system-x86 die x86-Systememulation und KVM-Nutzung bereit. Libvirt übernimmt die Verwaltung:
root@kvm1:~# apt-get install qemu-system-x86 qemu-utils \
libvirt-daemon-system libvirt-clients \
virtinst libguestfs-tools libosinfo-bin
Ein Administrationsbenutzer kann den Gruppen libvirt und libvirt-qemu hinzugefügt werden:
root@kvm1:~# adduser admin libvirt root@kvm1:~# adduser admin libvirt-qemu root@kvm1:~# virsh --connect qemu:///system list --all
virsh ist eines der wichtigsten Werkzeuge für die Verwaltung über Libvirt. Mit virsh list --all lässt sich sofort prüfen, ob die Verbindung zum lokalen Libvirt/QEMU-Stack funktioniert.
Damit virtuelle Maschinen direkt mit dem LAN kommunizieren können, wird auf jedem KVM-Node eine Linux-Bridge eingerichtet.
Die Bridge funktioniert aus Sicht der VMs ähnlich wie ein virtueller Ethernet-Switch.
Die genaue Netzwerkkonfiguration hängt davon ab, ob Debian mit ifupdown, systemd-networkd, NetworkManager oder einer anderen Methode verwaltet wird.
Ein vereinfachtes Beispiel für /etc/network/interfaces mit einer Bridge br0:
auto br0
iface br0 inet static
address 10.0.1.52/24
gateway 10.0.1.210
bridge_ports eno2
bridge_stp off
bridge_fd 0
Die IP-Adressen und das physische Interface müssen an die eigene Umgebung angepasst werden. In produktiven Umgebungen sollte die Bridge über redundante Links beziehungsweise ein passendes Bonding-Konzept angebunden sein.
Libvirt kann eine bereits vorhandene Host-Bridge direkt verwenden. Für die VMs genügt dann beispielsweise eine Netzwerkkonfiguration mit bridge=br0.
Eine zusätzliche Libvirt-Network-Definition ist für eine normale externe Linux-Bridge nicht zwingend notwendig.
Damit ist die Grundkonfiguration des KVM-Nodes abgeschlossen und die erste virtuelle Maschine kann eingerichtet werden.
Da die KVM-Nodes ohne lokale GUI betrieben werden, kann eine VM komfortabel über virt-install angelegt werden.
Das folgende Beispiel erstellt eine virtuelle Maschine mit 4 GByte RAM, zwei vCPUs, einer VirtIO-Netzwerkkarte und einer QCOW2-Disk auf dem gemeinsamen GFS2-Dateisystem:
admin@kvm1:~$ virt-install \ --name testvm \ --memory 4096 \ --vcpus 2 \ --cpu host-model \ --disk path=/kvm/storage/testvm.qcow2,size=40,format=qcow2,bus=virtio \ --network bridge=br0,model=virtio \ --cdrom /data/iso/debian-13.iso \ --graphics vnc,listen=127.0.0.1 \ --osinfo detect=on,require=off
Für die grafische Installationskonsole kann VNC lokal auf dem KVM-Host gebunden werden. Der entsprechende Display-Port lässt sich über Libvirt ermitteln:
admin@kvm1:~$ virsh vncdisplay testvm
Aus Sicherheitsgründen sollte eine unverschlüsselte VNC-Konsole nicht pauschal auf allen Interfaces veröffentlicht werden. Eine einfache Möglichkeit für Administrationszwecke ist ein SSH-Tunnel vom Admin-PC zum KVM-Host:
admin@pc:~$ ssh -L 5901:127.0.0.1:5901 admin@kvm1
Der lokale VNC-Viewer verbindet sich anschließend mit 127.0.0.1:5901.
Der VNC-Verkehr läuft damit durch den verschlüsselten SSH-Tunnel. In größeren Umgebungen sind zentral verwaltete Konsolenlösungen,
SPICE oder eine fertige Managementplattform meist komfortabler.
Die wichtigsten Aufgaben lassen sich mit virsh erledigen. Die folgende Liste zeigt eine kleine Auswahl:
admin@kvm1:~$ virsh list --all # Alle bekannten virtuellen Maschinen anzeigen admin@kvm1:~$ virsh console <name> # Textkonsole einer VM öffnen admin@kvm1:~$ virsh shutdown <name> # Gast sauber herunterfahren admin@kvm1:~$ virsh start <name> # VM starten admin@kvm1:~$ virsh reboot <name> # Gast neu starten admin@kvm1:~$ virsh destroy <name> # VM hart ausschalten – vergleichbar mit Power-Off admin@kvm1:~$ virsh undefine <name> # VM-Definition aus Libvirt entfernen admin@kvm1:~$ virsh migrate --live <name> qemu+ssh://<node>/system # Laufende VM auf einen anderen KVM-Node migrieren
Für eine Live-Migration müssen Quell- und Zielhost kompatible CPU-Features, passende QEMU-/Libvirt-Versionen, identische Netzwerke und Zugriff auf die benötigten VM-Daten besitzen. Bei gemeinsamem Storage müssen die virtuellen Platten nicht über das Migrationsnetz übertragen werden; hauptsächlich RAM- und Gerätezustand wechseln den Host.
Pacemaker kann virtuelle Maschinen als Cluster-Ressourcen verwalten. Sobald eine VM unter Kontrolle des Clusters steht, sollte sie nicht mehr unabhängig von Pacemaker gestartet oder gestoppt werden. Sonst interpretiert der Cluster einen manuellen Shutdown möglicherweise als Fehler und startet die VM erneut.
Eine Libvirt-VM kann über den Resource Agent VirtualDomain eingebunden werden. Die XML-Definition muss für alle
Nodes an einem konsistenten Pfad verfügbar sein. Das folgende Beispiel zeigt das Grundprinzip:
admin@kvm1:~$ virsh dumpxml testvm > /kvm/storage/config/testvm.xml
root@kvm1:~# pcs resource create vm-testvm ocf:heartbeat:VirtualDomain \
config=/kvm/storage/config/testvm.xml \
hypervisor=qemu:///system \
migration_transport=ssh \
meta allow-migrate=true
Danach kann Pacemaker den Zustand der VM überwachen und sie bei Bedarf auf einem anderen Node starten oder – wenn alle Voraussetzungen erfüllt sind – live migrieren. Für automatischen Start und Failover müssen außerdem Abhängigkeiten zum Storage modelliert werden: Die VM darf erst starten, wenn Multipath, Shared LVM und GFS2 verfügbar sind.
Eine Ressource kann beispielsweise auf einen anderen Node verschoben werden:
root@kvm1:~# pcs resource move vm-testvm kvm2 root@kvm1:~# pcs resource clear vm-testvm
Das anschließende pcs resource clear entfernt die temporäre Move-Constraint wieder.
Vor dem produktiven Einsatz müssen Failover, Fencing, Live-Migration und Wiederanlauf unter realistischen Lastbedingungen getestet werden.
Das hier gezeigte Beispiel vermittelt die technischen Zusammenhänge, ist aber noch keine vollständige Virtualisierungsplattform. Im täglichen Betrieb entstehen schnell zusätzliche Anforderungen: zentrale Übersicht aller VMs, rollenbasierte Administration, Console-Zugriff, Templates, Backup, Monitoring, Alarmierung, automatisierte Updates und ein nachvollziehbares Lifecycle-Management.
Auch Netzwerk und Storage sollten weiter optimiert werden. Dazu gehören redundante Switches und NICs, getrennte Cluster- und Storage-Netze, Multipath, ein getestetes Fencing-Konzept, Monitoring der Storage-Latenzen sowie klare Regeln für CPU-Kompatibilität und Live-Migration.
Besonders wichtig ist das Backup: Ein HA-Cluster ist kein Backup. Hochverfügbarkeit schützt vor bestimmten Host-Ausfällen, nicht vor versehentlichem Löschen, logischen Fehlern, Ransomware oder beschädigten Daten innerhalb einer VM. Deshalb benötigt auch ein KVM-Cluster eine eigenständige, regelmäßig getestete Backup- und Restore-Strategie.
Für eine selbst aufgebaute KVM-Plattform ist das eigene Know-how entscheidend. Wer die Flexibilität einer individuellen Lösung nutzen möchte, muss Betrieb, Dokumentation und Fehleranalyse dauerhaft beherrschen. Wer eine integrierte Oberfläche und fertige Betriebsfunktionen bevorzugt, sollte Lösungen wie Proxmox VE als KVM-basierte Virtualisierungsplattform in den Vergleich einbeziehen.
Ein KVM-Cluster besteht aus mehreren Linux-Hosts, die virtuelle Maschinen mit KVM/QEMU betreiben und über gemeinsame Cluster-Funktionen verwaltet werden. Je nach Architektur können Pacemaker und Corosync Hochverfügbarkeit, Ressourcensteuerung und Quorum übernehmen. Ein Cluster kann Wartungsarbeiten und Host-Ausfälle besser abfangen, ersetzt aber kein Backup.
KVM stellt die hardwaregestützte Virtualisierung im Linux-Kernel bereit. QEMU emuliert beziehungsweise virtualisiert die benötigte virtuelle Hardware und nutzt KVM zur Beschleunigung. Libvirt bildet darüber eine einheitliche Verwaltungsebene und stellt unter anderem das Kommandozeilenwerkzeug virsh sowie APIs für Management-Lösungen bereit.
KVM funktioniert mit vielen Linux-Distributionen. Wichtig sind stabile Kernel-, QEMU-, Libvirt- und Cluster-Pakete sowie ein nachvollziehbarer Update- und Support-Zyklus. Alle Cluster-Nodes sollten möglichst dieselbe Distribution und Versionslinie verwenden. Das Beispiel auf dieser Seite basiert auf Debian 13 „Trixie“.
Ja. Moderne Corosync-/Pacemaker-Konfigurationen unterstützen Zwei-Node-Cluster. Bei zwei Nodes ist ein zuverlässiges Fencing besonders wichtig, weil bei einer Kommunikationsunterbrechung verhindert werden muss, dass beide Seiten gleichzeitig auf gemeinsam genutzte Ressourcen schreiben. Drei Nodes vereinfachen viele Quorum-Szenarien und bieten zusätzliche Reserven für Wartung.
Nicht für jede KVM-Cluster-Architektur. Für das hier beschriebene GFS2-Konzept wird blockbasierter Shared Storage benötigt, auf den alle Nodes zugreifen können. Alternativen sind beispielsweise NFS, replizierter Storage oder verteilte Systeme wie Ceph. Für Live-Migration und HA muss in jedem Fall sichergestellt sein, dass der Zielhost auf konsistente VM-Daten zugreifen kann.
Mehrere Cluster-Nodes greifen bei GFS2 gleichzeitig auf dasselbe Blockdevice zu. Der Distributed Lock Manager koordiniert Sperren zwischen den Hosts und verhindert, dass konkurrierende Zugriffe Dateisystemstrukturen unkontrolliert verändern. Zusammen mit Quorum und Fencing ist DLM deshalb ein zentraler Bestandteil eines sicheren GFS2-Clusters.
Fencing isoliert einen fehlerhaften oder nicht eindeutig erreichbaren Cluster-Node zuverlässig von gemeinsam genutzten Ressourcen. STONITH ist der in Pacemaker gebräuchliche Begriff dafür. Typische Verfahren verwenden IPMI, iDRAC, iLO, PDUs oder Storage-basierte Mechanismen. Ohne funktionierendes Fencing besteht bei Shared Storage die Gefahr von Split Brain und Datenkorruption.
Bei einer Live-Migration wird eine laufende VM von einem Host auf einen anderen verschoben. Dafür benötigen die Hosts kompatible CPU-Features, passende QEMU-/Libvirt-Versionen, dieselben virtuellen Netzwerke und Zugriff auf die VM-Datenträger. Bei gemeinsamem Storage bleiben die virtuellen Platten am gleichen Ort; übertragen werden hauptsächlich Arbeitsspeicher und Gerätezustand.
Nein. Snapshots eignen sich für kurzfristige Zustände vor Tests oder Updates, sind aber kein unabhängiges Backup. Lange Snapshot-Ketten können Performance und Verwaltung verschlechtern. Für den Schutz vor Datenverlust werden getrennte Backups mit definierten Aufbewahrungszeiten und regelmäßig getesteten Restore-Prozessen benötigt.
Eine selbst aufgebaute KVM-Umgebung bietet maximale Flexibilität, verlangt aber viel eigenes Linux-, Storage- und Cluster-Know-how. Proxmox VE nutzt ebenfalls QEMU/KVM, integriert jedoch Management, Cluster, HA, Storage und weitere Betriebsfunktionen in einer fertigen Plattform. Welche Variante wirtschaftlicher ist, hängt von Anforderungen, Personal, Supportbedarf und vorhandener Infrastruktur ab.
Zuerst sollten CPU-Kompatibilität, QEMU-/Libvirt-Versionen, Netzwerk, Firewall, MTU, Storage-Zugriff und die VM-Konfiguration geprüft werden. Hilfreich ist ein Minimaltest mit einer kleinen VM ohne Passthrough oder Spezialhardware. Wenn diese migriert werden kann, liegt die Ursache häufig in einer besonderen VM-Komponente oder einer Host-Abweichung.
