vectorwin - stock.adobe.com
VM-Live-Migration in Proxmox VE Schritt für Schritt
Live Migration in Proxmox VE gelingt mit stabilem Cluster und passender Storage Strategie. ZFS-Replikation und Ceph bringen Tempo. Unsere Checkliste und Tipps verhindern Ausfälle.
Proxmox VE verschiebt laufende virtuelle Maschinen im aktiven Betrieb auf einen anderen Knoten und setzt CPU-Zustände, RAM-Inhalte und die Gerätekonfiguration ohne merkliche Unterbrechung fort.
Wir zeigen die Einrichtung, die relevanten Einstellungen, Fehlerquellen im Cluster sowie Leistungsgrenzen bei gemeinsamem und lokalem Storage. Der Text beschreibt die Vorgänge und deren wichtige Aspekte.
Sinnvoll ist zum Beispiel der Einsatz von Ceph als Cluster-Storage, da hier die Live-Migration schnell ablaufen kann, weil die VM-Dateien an Ort und Stelle bleiben und nur die Verweise auf den neuen Knoten umgeleitet werden.
Grundlagen der Cluster-Architektur
Ein funktionierender Proxmox-Cluster bildet die Basis jeder Migration. Alle beteiligten Hosts müssen gemeinsam im Cluster eingebunden sein, identische oder kompatible CPU-Befehlssätze bereitstellen und eine stabile Netzwerkverbindung besitzen. Migrationen übertragen RAM-Seiten, CPU-Register und Gerätezustände über das interne Cluster-Netz. Die Knoten müssen online sein und ein gültiges Quorum melden. Der Status lässt sich im Terminal mit dem Befehl pvecm status prüfen. Bei Quorate: Yes stehen alle Clusteraktionen zur Verfügung. Bricht das Quorum weg, stoppt Proxmox sämtliche Vorgänge, die den Clusterzustand verändern würden. Migrationen, HA-Abläufe oder Replikationsvorgänge bleiben dann gesperrt.
Das Quorum schützt vor Split-Brain-Situationen. Ohne abgestimmten Cluster-Status könnten mehrere Hosts gleichzeitig dieselbe VM verwalten oder voneinander abweichende Datensätze erzeugen. Eine Live-Migration setzt daher zwingend einen konsistenten Cluster voraus.
Speicherarchitektur und Auswirkungen auf die Migration
Der Speichertyp bestimmt das gesamte Migrationsverhalten. Bei gemeinsam genutzten Volumes wie NFS, iSCSI oder Ceph verschiebt Proxmox ausschließlich den Arbeitsspeicher und die Gerätezustände. Die virtuellen Festplatten laufen weiter auf dem unveränderten Storage, wodurch der Transfer nahezu ohne Ausfall erfolgt und sehr schnell ablaufen kann. Liegt die VM dagegen auf lokalem Storage, übertragen die Knoten zusätzlich die VM-Disks. Das führt zu längeren Transferzeiten. In solchen Szenarien lohnt sich der Einsatz von ZFS-Replikation.
Darüber erzeugt Proxmox regelmäßig Snapshots und synchronisiert Änderungen auf einen Zielknoten. Die Replikation hält identische Datenbestände auf mehreren Hosts bereit. Bei der späteren Migration überträgt das System nur die RAM-Daten, da die VM-Disks bereits aktuell auf dem Ziel liegen. Ohne Replikation kopiert Proxmox die komplette virtuelle Festplatte über das Netzwerk. Größere Volumes bremsen den Migrationsvorgang spürbar aus. Replikation sollte in solchen Clustern daher zum Standard gehören.
Replikation einrichten und prüfen
Für VMs auf lokalem ZFS-Speicher empfiehlt sich die Einrichtung eines Replikationsjobs im Menü Replication. Das gilt sowohl auf VM-Ebene als auch auf der Cluster-Verwaltung im Menü Datacenter. Die Datacenter-Ansicht dient der übergeordneten Verwaltung aller Aufträge. Dort lassen sich Jobs aktivieren, deaktivieren oder erneut starten. Die konkrete Zuordnung einer VM zum Zielknoten erfolgt im VM-Menü.
Add öffnet den Dialog zur Anlage eines neuen Jobs. Der Zielknoten muss denselben ZFS-Pool-Namen besitzen, da Proxmox ZFS-Snapshots verwendet. Im Feld Schedule wird das Synchronisationsintervall gesetzt, zum Beispiel alle fünfzehn Minuten. Rate limit begrenzt die Bandbreite des Replikationsverkehrs. Mit der Option Enabled lässt sich der Job aktivieren.
Nach dem ersten vollständigen Transfer sendet Proxmox ausschließlich inkrementelle Snapshots. Im Menüpunkt Replication muss bei Status der Wert OK stehen. Last Sync zeigt den zuletzt erfolgreichen Abgleich.
Fehlerquellen vor der Migration
Migrationen schlagen häufig aus strukturellen Gründen fehl. Ein typisches Hindernis ist ein verbundenes lokales ISO-Image. Wenn in der VM bei CD/DVD Drive noch eine lokale ISO-Datei verbunden ist, verweigert Proxmox die Migration. Die Korrektur erfolgt im Menü Hardware. Dort wird das CD-Laufwerk bearbeitet und auf Do not use any media gestellt.
Nicht migrierbare Geräte wie PCI-Passthrough, USB-Geräte oder einzelne Hardwarebindungen verhindern den Transfer ebenfalls. Solche Geräte müssen vorher entfernt werden. Bei Versionsabweichungen der Knoten lehnt Proxmox den Vorgang ab. Die Zielknoten benötigen mindestens die gleiche oder eine neuere Version. Aus diesen Gründen ist es sinnvoll, bereits deutlich vor Live-Migrationen sicherzustellen, dass keine unnötigen Hindernisse die Replikation verhindern.
Live-Migration über die Verwaltungsoberfläche
Die Migration startet über das Kontextmenü der VM mit dem Eintrag Migrate. Der Dialog zeigt Quell- und Zielknoten sowie den Migrationsmodus. Bei gemeinsamem Storage steht die Online-Migration zur Verfügung, also echte Live-Migration. Bei lokalem Storage erscheint der Hinweis, dass Disks übertragen werden, was natürlich deutlich länger dauert.
Proxmox prüft automatisch, ob Konflikte bestehen. Liegt ein Problem vor, wird der Hinweis direkt im Dialog angezeigt. Nach dem Start zeigt Proxmox den Live-Output mit RAM-Übertragungsrate, Cache-Größe, Tunnel-Aufbau und Dauer. Die Migration beendet sich mit der Ausgabe TASK OK. Die VM erscheint danach unter den VMs des Ziel-Hosts.
Live-Migration über die Shell
Die Shell bietet den Zugriff auf alle Parameter. Der Befehl qm migrate verschiebt die VM direkt. Die Syntax lautet:
qm migrate <VMID> <Zielknoten> --online
Die Option --online löst die Live-Migration aus. Befindet sich die VM auf lokalem Storage, kann die Option --with-local-disks genutzt werden. Damit überträgt Proxmox zusätzlich die VM-Disks, sofern keine Replikation besteht.
--delete entfernt die ursprünglichen Images nach erfolgreicher Migration auf dem Quellknoten.
--bwlimit <Wert> begrenzt die Übertragungsrate.
--migration_type insecure nutzt einen unverschlüsselten Tunnel für Testumgebungen.
Die Shell zeigt detaillierte Informationen an: Aufbau des Tunnels, Durchsatz, Anzahl der RAM-Seiten, Umschaltzeit des Gasts und die Gesamtdauer. Ein typischer Transfer aus den gelieferten Logs erzielt Raten über 900 MiB/s und schaltet den Gast in wenigen Millisekunden um.
Leistungsgrenzen und Architekturgrenzen
Die Leistungsfähigkeit der Live-Migration hängt von mehreren Faktoren ab. Das Cluster-Netz bestimmt die Geschwindigkeit der RAM-Synchronisation. Bei Gigabit-Netzen zeigen sich Grenzen bei größeren RAM-Beständen. Bei 10-GBit-Umgebungen laufen Migrationen deutlich schneller. Die Cache-Einstellungen der Migration begrenzen den Umfang der RAM-Seiten, die Proxmox in einem Durchlauf überträgt.
Große VM-Disks auf lokalem Storage verlängern den Vorgang massiv, sofern keine Replikation existiert. Auch hohe I/O-Last im Gast behindert die Migration, da Proxmox geänderte RAM-Seiten nach dem Pre-Copy-Prinzip erneut übertragen muss.
Eine weitere Grenze ergibt sich durch die CPU-Architektur. Abweichende Befehlssätze zwischen den Knoten können dazu führen, dass der Zielhost den VM-Prozessorzustand nicht fortsetzen kann. Migrationen müssen deshalb zwischen kompatiblen CPUs erfolgen.
Fazit
Proxmox VE bietet eine kontrollierbare Live-Migration, deren Effizienz maßgeblich von der Storage-Architektur, der Cluster-Stabilität und der Netzwerkleistung abhängt. Gemeinsames Storage ermöglicht nahezu unterbrechungsfreie Verschiebungen. Lokaler ZFS-Storage profitiert von Replikation. Die dargestellten Abläufe bieten sowohl über die Oberfläche als auch über die Shell eine vollständige Grundlage zur Einrichtung, Optimierung und Fehlersuche in produktiven Umgebungen.
Checkliste: Live-Migration einrichten Schritt für Schritt
Die folgenden Anweisungen ermöglichen die vollständige Umsetzung in einer realen Proxmox-Umgebung:
- Im Terminal pvecm status ausführen. Der Cluster muss Quorate: Yes melden. Alle Knoten müssen online sein.
- Gemeinsames Storage ermöglicht direkte Live-Migration. Lokaler ZFS-Storage benötigt Replikation für optimale Abläufe.
- Im Menü der VM Replication öffnen und über Add Zielknoten, Schedule und Rate limit setzen. Status prüfen, bis OK erscheint.
- Unter Hardware lokale ISO-Dateien trennen und problematische Geräte entfernen.
- Im Kontextmenü der VM Migrate wählen. Zielknoten setzen, Modus prüfen, Vorgang starten.
- Den Log-Output prüfen. Abschließen muss der Vorgang mit TASK OK. Danach erscheint die VM auf dem Zielhost.
Shell-Migration nutzen:
qm migrate <VMID> <Zielknoten> --online
