# Proxmox Live Migration: VMs im laufenden Betrieb verschieben

TL;DR / Management Summary Die Live Migration ist eines der beeindruckendsten Features moderner Hypervisor. Sie ermöglicht das Verschieben einer laufenden VM von einem physischen Proxmox-Knoten auf einen anderen, ohne dass der User eine Unterbrechung bemerkt. Ein Senior Admin nutzt dieses Werkzeug für Wartungsarbeiten am Host oder zur Lastverteilung im Cluster. Voraussetzung für eine reibungslose Migration sind ein schnelles Management-Netzwerk (min. 10 Gbit) und ein gemeinsamer Zugriff auf die Festplatten-Images (Shared Storage).

# 1. Wie funktioniert Live Migration?

Der fliegende RAM-Inhalt.

Bei der Live Migration wird nicht die Festplatte verschoben (diese liegt idealerweise auf einem SAN/NAS), sondern nur der Zustand der CPU und der Inhalt des Arbeitsspeichers (RAM).

1. Phase 1: Proxmox bereitet den Ziel-Host vor.
2. Phase 2: Der RAM wird im Hintergrund kopiert, während die VM weiterläuft (Iterativer Prozess).
3. Phase 3 (Stun): Wenn nur noch wenige MB RAM fehlen, wird die VM für Millisekunden angehalten.
4. Phase 4: Der Rest wird übertragen, und die VM nimmt ihre Arbeit am Ziel-Host exakt dort auf, wo sie gestoppt wurde.

# 2. Voraussetzungen für Null-Downtime

Damit der Umzug gelingt.

# 1. Shared Storage (Zwingend für Speed)

Die VHDX/RAW Datei muss für beide Hosts gleichzeitig erreichbar sein (z.B. via NFS, iSCSI oder Ceph).

• Hinweis: Migration ohne Shared Storage (“Storage Live Migration”) ist möglich, dauert aber bei großen Platten Stunden statt Sekunden.

# 2. Netzwerk

Nutzen Sie eine dedizierte Netzwerkkarte für den Migrations-Traffic.

• Aktion: Setzen Sie in den Datacenter-Optionen das Migration Network auf ein spezifisches VLAN (z.B. 10G Storage VLAN).

# 3. Deep Dive: CPU-Kompatibilität

Der kleinste gemeinsame Nenner.

Ein häufiger Fehler: Host A hat eine neue Intel CPU, Host B eine alte AMD CPU.

• Problem: Wenn die VM CPU-Instruktionen nutzt, die es am Ziel nicht gibt, stürzt sie nach der Migration sofort ab.
• Lösung: Stellen Sie den CPU-Typ der VM auf kvm64 (für maximale Kompatibilität) oder auf den Typ des ältesten Hosts im Cluster.

# 4. Day-2 Operations: Automatisierte Migration

Load Balancing.

Nutzen Sie den Proxmox HA-Manager (Artikel 676), um VMs bei hoher Last automatisch zu verschieben.

• Aktion: Wenn ein Host zu 90% ausgelastet ist, kann ein Script via API (pvesh) VMs auf einen “kühleren” Host schieben.

# 5. Troubleshooting & “War Stories”

Wenn die Migration bei 99% hängen bleibt.

# Top 3 Fehlerbilder

1. Symptom: Migration schlägt fehl mit “Migration speed too low”.

   • Ursache: Die VM ändert ihren RAM-Inhalt schneller, als das Netzwerk ihn zum Ziel-Host kopieren kann.
   • Lösung: Bandbreite erhöhen oder die VM kurzzeitig drosseln.

2. Symptom: VM verliert nach der Migration die Netzwerkverbindung.

   • Ursache: Die virtuelle Bridge (z.B. vmbr10) existiert am Ziel-Host nicht.
   • Fix: Einheitliche Netzwerk-Namen über alle Cluster-Knoten hinweg sicherstellen.

3. Symptom: Migration von VMs mit durchgereichten USB-Geräten (Artikel 674).

   • Lösung: Geht nicht! Physische Hardware-Abhängigkeiten blockieren die Live-Migration.

# “War Story”: Der “Ping-Loss” Skandal

Ein Admin migrierte eine hochfrequentierte E-Commerce Webseite (1000 Requests/Sek) zwischen zwei Knoten. Das Ergebnis: Genau im Moment des Umschaltens (Phase 3) verloren 50 User ihre Session. Die Ursache: Der physische Switch brauchte zu lange, um zu lernen, dass die MAC-Adresse der VM nun an einem anderen Port zu finden war (MAC Address Table Update). Lösung: Wir aktivierten das Senden von “Gratuitous ARP” Paketen am Ende der Migration und stellten die Switch-Ports auf Fast Aging. Lehre: Live-Migration ist nicht nur ein Hypervisor-Feature, sondern erfordert einen performanten Layer-2 Backbone.

# 6. Monitoring & Reporting

Statistiken des Umzugs.

# Migration Logs (Shell)

Sie finden die detaillierten Statusberichte unter: /var/log/pve/tasks/[task-id]

• KPI: Transferred RAM (MB/s). Ein Wert von > 800 MB/s deutet auf einen gesunden 10G Link hin.

# 7. Fazit & Empfehlung

Live Migration ist das ultimative Flexibilitäts-Tool.

• Empfehlung: Nutzen Sie 10 Gbit/s SFP+ für Ihren Migrations-Traffic. Alles darunter fühlt sich bei modernen RAM-Größen (> 32 GB) zäh an.
• Wichtig: Testen Sie die Migration Ihrer kritischen SQL-VMs in einer ruhigen Minute, bevor Sie den gesamten Host für Wartungsarbeiten leeren.

# Anhang: Cheatsheet (CLI Migration)

# Referenzen

• Proxmox VE: QEMU Migration Documentation
• Red Hat: KVM Live Migration Internals
• Cisco: Virtual Machine Mobility Best Practices