Proxmox Live-Migration zwischen Clustern: VM-Umzug ohne Downtime

Die klassische Live-Migration innerhalb eines Proxmox-Clusters ist seit Jahren Routine: ein Klick im Webinterface, und die VM wandert ohne Unterbrechung auf einen anderen Node. Sobald die Maschine aber den Cluster verlassen soll — etwa beim Hardware-Refresh, beim Umzug ins neue Rechenzentrum oder bei der Aufteilung eines gewachsenen Clusters — wurde es bisher schmerzhaft: Backup, Restore, Reboot, Downtime. Mit qm remote-migrate aus Proxmox VE 8 ist diese Lücke geschlossen. VMs lassen sich live zwischen zwei vollständig unabhängigen Clustern verschieben, inklusive RAM-Inhalt und laufenden Datenbankverbindungen.

Wir nutzen die Funktion bei DATAZONE inzwischen produktiv für Migrationen, bei denen früher nur das Wartungsfenster am Wochenende blieb. In diesem Beitrag zeigen wir, wie der Befehl funktioniert, welche Vorbereitung notwendig ist und wo die Grenzen liegen.

Was qm remote-migrate genau macht

Innerhalb eines Clusters teilen sich alle Nodes eine gemeinsame Konfigurationsdatenbank (pmxcfs) und Corosync-Quorum. Zwischen zwei getrennten Clustern existiert dieses Vertrauensverhältnis nicht. qm remote-migrate löst das Problem über eine HTTPS-API-Verbindung mit Token-Authentifizierung. Der Quellnode öffnet einen WebSocket zum Zielcluster, überträgt die VM-Konfiguration, repliziert die Disks über das Netzwerk und führt am Ende den klassischen QEMU-Live-Migration-Handshake durch.

Das Ergebnis: dieselbe VM-ID oder eine neue, dieselbe MAC-Adresse, der RAM wandert mit — offene SSH-Sessions und Datenbank-Transaktionen überleben den Umzug. Im Gastsystem bleibt eine Anomalie sichtbar: die Uhr macht einen kleinen Sprung, sonst nichts.

Voraussetzungen und Vorbereitung

Bevor der eigentliche Befehl laufen kann, müssen einige Dinge stimmen. Wir gehen die Checkliste der Reihe nach durch.

Komponente	Anforderung	Hinweis
PVE-Version	8.1 oder neuer auf beiden Seiten	Wir empfehlen 8.4+ wegen Bugfixes bei NVMe-Mappings
Netzwerk	Direkte HTTPS-Erreichbarkeit Port 8006	VPN oder MPLS-Strecke, mindestens 1 Gbit/s
Storage	Kompatible Typen auf Ziel-Seite	LVM-Thin, ZFS, Ceph RBD werden unterstützt
API-Token	Auf Zielcluster mit ausreichend Rechten	Privilege Separation deaktivieren
Fingerprint	SHA-256 des Ziel-Zertifikats	Aus pveproxy-ssl.pem auslesen

Der API-Token wird auf dem Zielcluster als Realm-Benutzer angelegt, typischerweise migrate@pam mit einem Token namens xfer. Wichtig: bei der Tokenerstellung muss das Häkchen bei “Privilege Separation” entfernt werden, sonst greifen die Rollenrechte nicht durch.

Zertifikatsvertrauen aufbauen

Da die Cluster keine gemeinsame CA haben, muss der Quellcluster den Fingerprint des Ziels explizit kennen. Das funktioniert am einfachsten so:

# Auf einem Node des Zielclusters Fingerprint auslesen
openssl x509 -in /etc/pve/local/pveproxy-ssl.pem \
  -noout -fingerprint -sha256 | sed 's/://g'

# Beispielausgabe
SHA256 Fingerprint=A1B2C3D4E5F6...

Diesen String benötigen Sie beim Migrationsbefehl. Wer eine eigene PKI mit Let’s Encrypt oder interner CA betreibt, kann den Fingerprint auch über die ACME-Schnittstelle abrufen lassen — entscheidend ist, dass der Wert exakt mit dem aktiven Zertifikat übereinstimmt.

Der Migrationsbefehl in der Praxis

Sobald Token und Fingerprint vorliegen, ist die eigentliche Migration ein einzelner Befehl auf dem Quellnode. Hier ein vollständiges Beispiel für eine VM mit zwei Disks und einer Netzwerkkarte:

qm remote-migrate 142 248 \
  'host=pve-target.example.com,apitoken=PVEAPIToken=migrate@pam!xfer=8f3c...,fingerprint=A1B2C3D4E5F6...' \
  --target-bridge vmbr0 \
  --target-storage 'local-lvm:nvme-pool,backup-disk:hdd-pool' \
  --online

Was hier passiert:

• 142 ist die VM-ID auf der Quelle, 248 die neue ID am Ziel
• host=... enthält FQDN, Token und Fingerprint des Zielclusters
• --target-bridge mappt das Quell-Netzwerk auf die Ziel-Bridge
• --target-storage erlaubt unterschiedliche Storage-Mappings pro Disk
• --online macht aus dem Offline-Move eine echte Live-Migration

Bei einer 32-GB-VM mit 200 GB Disks über eine 10-Gbit-Strecke rechnen wir mit etwa 5—8 Minuten Gesamtdauer. Die eigentliche Switch-Over-Phase, in der die VM kurz pausiert, liegt bei deutlich unter einer Sekunde.

Typische Stolperfallen

In Projekten begegnen uns immer wieder dieselben Hürden. Die wichtigsten Punkte aus unserer Praxis:

Storage-Mapping vergessen: Wenn die Quelle local-zfs heißt und das Ziel tank-ssd, muss das explizit über --target-storage gemappt werden. Ohne Mapping bricht die Migration mit einem Storage-Not-Found-Fehler ab.

CPU-Typ inkompatibel: Steht die VM auf host-CPU und unterscheiden sich Quell- und Ziel-CPU-Generation, schlägt der Live-Switch fehl. Wir setzen vor der Migration einen gemeinsamen Nenner wie x86-64-v3 und starten die VM einmal neu — danach läuft die Migration sauber durch.

Snapshots und Templates: VMs mit aktiven Snapshots oder solche, die selbst als Template dienen, lassen sich nicht remote migrieren. Snapshots vorher löschen, Templates klonen und erst den Klon umziehen.

Bandbreitenlimit: Standardmäßig nutzt die Migration die gesamte verfügbare Bandbreite. Über --bwlimit 500000 (500 MB/s) lässt sich das produktive Netzwerk schonen.

HA-Manager: Steht die VM unter HA-Kontrolle, muss sie vorher aus der HA-Gruppe entfernt werden. Nach erfolgreicher Migration im Zielcluster wieder hinzufügen.

Anwendungsfälle aus der Praxis

Drei typische Szenarien, in denen wir die Cross-Cluster-Migration einsetzen:

1. Hardware-Refresh ohne Wartungsfenster: Der neue Cluster steht parallel zum alten, beide laufen produktiv. VMs wandern nach und nach über, der alte Cluster wird Node für Node leer und abgeschaltet.
2. Datacenter-Umzug: Standortwechsel von Standort A nach B mit kurzer Glasfaserstrecke dazwischen. VMs migrieren live, niemand merkt etwas.
3. Cluster-Split: Ein gewachsener Cluster wird in zwei kleinere Einheiten geteilt — etwa um Tenants zu trennen oder die Quorum-Komplexität zu reduzieren.

In allen drei Fällen war früher nur Backup-Restore mit anschließendem Reboot möglich. Heute läuft die Anwendung durch.

Grenzen und Empfehlungen

Trotz aller Fortschritte ist qm remote-migrate kein Wundermittel. Bei sehr großen Disks jenseits von 10 TB raten wir zur Vorabsynchronisation über pvesm export und pvesm import, danach folgt nur noch das RAM-Delta. Auch GPU-Passthrough-VMs lassen sich nicht live migrieren — der Gerätekontext geht beim Switch verloren.

Für die Planung größerer Migrationen empfehlen wir, vorher ein Pilotsystem mit Testlast durchzuspielen. Wir bauen bei Proxmox-Beratungsprojekten regelmäßig eine identisch konfigurierte Test-VM auf, migrieren sie inklusive Lastgenerator und messen Switch-Over-Zeiten — erst danach gehen wir an die produktiven Workloads. In Kombination mit einem soliden Backup-Konzept auf Proxmox Backup Server liegen die Risiken deutlich unter denen einer klassischen Migration mit Downtime.

Fazit

qm remote-migrate schließt eine der letzten großen Lücken im Proxmox-Ökosystem. Hardware-Refresh, Standortwechsel und Cluster-Restrukturierung lassen sich heute ohne nächtliche Wartungsfenster durchführen — vorausgesetzt, API-Token, Zertifikatsvertrauen und Storage-Mappings stimmen.

DATAZONE unterstützt Sie bei der Planung und Umsetzung von Cross-Cluster-Migrationen, dem Aufbau paralleler Proxmox-Umgebungen und dem reibungslosen Übergang ohne Geschäftsunterbrechung. Sprechen Sie uns an unter kontakt@datazone.de — wir analysieren Ihre Ausgangslage und entwerfen einen Migrationspfad, der zu Ihren Servicezeiten passt.