Proxmox Live-Migration: VMs ohne Downtime zwischen Nodes verschieben

Wartungsarbeiten an einem Proxmox-Node — Firmware-Updates, RAM-Erweiterung oder Kernel-Upgrades — bedeuten klassischerweise Downtime für alle darauf laufenden VMs. Mit der Live-Migration von Proxmox VE gehört das der Vergangenheit an. VMs werden im laufenden Betrieb von einem Node auf einen anderen verschoben, ohne dass Benutzer oder Dienste etwas davon bemerken. In diesem Artikel zeigen wir, wie die Migration funktioniert, welche Voraussetzungen gelten und wie Sie das Maximum an Geschwindigkeit und Zuverlässigkeit herausholen.

Was ist Live-Migration und warum ist sie wichtig?

Bei einer Live-Migration wird der gesamte Arbeitsspeicher einer laufenden VM schrittweise auf einen Ziel-Node kopiert, während die VM weiterläuft. Erst im letzten Schritt — der sogenannten Switchover-Phase — wird die VM für wenige Millisekunden pausiert, die letzten geänderten Speicherseiten übertragen und die VM auf dem Ziel-Node fortgesetzt. Für Netzwerkverbindungen und laufende Anwendungen ist dieser Vorgang transparent.

Das ermöglicht:

• Wartung ohne Downtime: Nodes können einzeln aktualisiert oder repariert werden, ohne den Betrieb zu unterbrechen.
• Lastverteilung: VMs lassen sich zur Laufzeit auf weniger ausgelastete Nodes verschieben.
• Hardware-Austausch: Defekte Nodes können kontrolliert geräumt werden, bevor sie heruntergefahren werden.

Voraussetzungen für die Live-Migration

Damit die Live-Migration zuverlässig funktioniert, müssen mehrere Bedingungen erfüllt sein:

Shared Storage: Alle VM-Disks müssen auf einem gemeinsamen Storage liegen, der von beiden Nodes erreichbar ist — zum Beispiel Ceph, NFS, iSCSI oder GlusterFS. Ohne Shared Storage wird automatisch eine Offline-Migration durchgeführt, bei der die Disks vollständig kopiert werden.

Kompatible CPU-Familie: Der Ziel-Node muss die gleiche CPU-Architektur und -Familie verwenden. Eine VM, die auf einem Intel-Xeon-Node läuft, lässt sich nicht live auf einen AMD-EPYC-Node verschieben. Innerhalb derselben Familie (z. B. verschiedene Xeon-Generationen) hilft der CPU-Typ x86-64-v2-AES oder ein anderer generischer Typ, Kompatibilitätsprobleme zu vermeiden.

Netzwerkverbindung: Beide Nodes müssen über das Cluster-Netzwerk erreichbar sein. Für produktive Umgebungen empfehlen wir ein dediziertes Migrationsnetzwerk (10 GbE oder schneller), um den regulären VM-Traffic nicht zu belasten.

Online- vs. Offline-Migration

Merkmal	Online-Migration	Offline-Migration
VM-Status	Läuft weiter	Wird heruntergefahren
Downtime	Millisekunden	Minuten
Shared Storage	Erforderlich	Nicht erforderlich
Disk-Kopie	Nur RAM	Komplette VM-Disks
Dauer	Sekunden bis Minuten	Minuten bis Stunden

Die Offline-Migration ist die richtige Wahl, wenn kein Shared Storage vorhanden ist oder wenn Sie eine VM gleichzeitig auf einen anderen Storage-Typ verschieben möchten.

Migration über die Weboberfläche

Die einfachste Methode: Rechtsklick auf die VM in der Proxmox-Weboberfläche und Migrate auswählen. Im Dialog wählen Sie den Ziel-Node und — bei lokalen Disks — den Ziel-Storage. Proxmox erkennt automatisch, ob eine Online- oder Offline-Migration möglich ist, und zeigt die entsprechenden Optionen an.

Für laufende VMs mit Shared Storage erscheint die Option Online. Ein Klick auf Migrate startet den Vorgang. Der Fortschritt wird im Task-Log in Echtzeit angezeigt.

Migration per CLI mit qm migrate

Für Automatisierung und Skripting ist die CLI der bevorzugte Weg:

# Live-Migration einer laufenden VM (ID 101) auf Node pve2
qm migrate 101 pve2 --online

# Offline-Migration mit Disk-Verschiebung auf Ziel-Storage
qm migrate 101 pve2 --targetstorage local-zfs

# Migration mit Bandbreitenlimit (in MiB/s)
qm migrate 101 pve2 --online --migration_network 10.10.10.0/24 --bwlimit 500

Der Parameter --online erzwingt die Live-Migration. Ohne ihn wird die VM heruntergefahren, verschoben und auf dem Ziel-Node wieder gestartet.

Mehrere VMs gleichzeitig migrieren

Vor einer geplanten Wartung müssen oft alle VMs eines Nodes verschoben werden. Ein einfaches Bash-Skript übernimmt das:

# Alle laufenden VMs von diesem Node auf pve2 migrieren
for VMID in $(qm list | awk 'NR>1 && $3=="running" {print $1}'); do
  echo "Migriere VM $VMID nach pve2..."
  qm migrate "$VMID" pve2 --online
done

Alternativ können Sie über den HA-Manager den Node in den Wartungsmodus versetzen — dazu später mehr.

Storage-Migration: Von lokal zu Shared

Manchmal müssen VM-Disks von lokalem Storage (z. B. local-lvm) auf Shared Storage (z. B. Ceph oder NFS) verschoben werden, um Live-Migration überhaupt zu ermöglichen:

# VM-Disk von local-lvm auf Ceph-Pool verschieben
qm disk move 101 scsi0 ceph-pool

# Anschließend Live-Migration durchführen
qm migrate 101 pve2 --online

Dieser Vorgang kann im laufenden Betrieb der VM durchgeführt werden — die Disk wird im Hintergrund kopiert und anschließend nahtlos umgeschaltet.

Migrationsgeschwindigkeit optimieren

Die Dauer einer Live-Migration hängt primär von der RAM-Größe der VM und der verfügbaren Netzwerkbandbreite ab. Folgende Maßnahmen beschleunigen den Vorgang:

Dediziertes Migrationsnetzwerk: Unter Datacenter > Options > Migration Settings können Sie ein separates Netzwerk für Migrationen konfigurieren. Ein 10-GbE-Link reduziert die Migrationszeit einer VM mit 32 GB RAM von mehreren Minuten auf unter 30 Sekunden.

# Migrationsnetzwerk per CLI konfigurieren
pvesh set /cluster/options --migration '{"network":"10.10.10.0/24","type":"secure"}'

Bandbreitenlimit anpassen: Standardmäßig begrenzt Proxmox die Migrationsbandbreite. Für geplante Wartungsfenster können Sie das Limit erhöhen oder entfernen.

Schreibintensive VMs: VMs mit hoher Schreibrate im RAM (z. B. Datenbanken) erfordern mehr Iterationen, da geänderte Seiten erneut übertragen werden müssen. In extremen Fällen kann Proxmox einen kurzen Freeze erzwingen, um die Migration abzuschließen.

HA-Manager und automatische Migration

Der Proxmox HA-Manager überwacht den Zustand aller Nodes im Cluster. Fällt ein Node aus, werden dessen HA-verwaltete VMs automatisch auf überlebenden Nodes neu gestartet. Für geplante Wartungen bietet der HA-Manager einen Wartungsmodus:

# Node in den Wartungsmodus versetzen — alle HA-VMs werden automatisch migriert
ha-manager crm-command node-maintenance enable pve1

# Nach der Wartung den Modus deaktivieren
ha-manager crm-command node-maintenance disable pve1

Im Wartungsmodus migriert der HA-Manager alle verwalteten VMs kontrolliert auf andere Nodes. Nach Abschluss der Wartung können die VMs manuell oder per Policy zurückverschoben werden.

Troubleshooting: Häufige Probleme

CPU-Inkompatibilität: Die Fehlermeldung kvm: warning: host doesn't support requested feature deutet auf unterschiedliche CPU-Generationen hin. Lösung: In den VM-Einstellungen den CPU-Typ auf einen generischen Typ wie x86-64-v2-AES setzen.

Lock-Dateien: Eine fehlgeschlagene Migration hinterlässt manchmal eine Lock-Datei, die weitere Aktionen blockiert. Diese lässt sich manuell entfernen:

# Lock entfernen
qm unlock 101

Netzwerk-Timeouts: Timeouts während der Migration deuten auf Netzwerkprobleme oder zu hohe Schreiblast in der VM hin. Prüfen Sie die Netzwerkverbindung zwischen den Nodes und erwägen Sie ein dediziertes Migrationsnetzwerk.

Lokale Ressourcen: VMs mit PCI-Passthrough-Geräten (z. B. GPUs) oder lokalen USB-Geräten können nicht live migriert werden. Entfernen Sie die Gerätezuweisung vor der Migration oder nutzen Sie die Offline-Migration.

Monitoring mit DATAZONE Control

In Clustern mit vielen Nodes und VMs wird die Übersicht über Migrationsvorgänge schnell unübersichtlich. DATAZONE Control protokolliert alle Migrationen zentral, überwacht die Cluster-Gesundheit und alarmiert bei fehlgeschlagenen Migrationen oder HA-Failover-Ereignissen. So behalten Sie auch in komplexen Multi-Node-Umgebungen den Überblick.

---

Sie planen eine Proxmox-Cluster-Umgebung mit Live-Migration oder benötigen Unterstützung bei der Optimierung? Kontaktieren Sie uns — wir konzipieren und betreuen Ihre Proxmox-Infrastruktur für maximale Verfügbarkeit.