# Proxmox VM Migration & Failover: Das Zusammenspiel von HA & Mobility

TL;DR / Management Summary In einem Proxmox-Cluster ist die Fähigkeit, VMs zwischen physischen Hosts zu verschieben, die Basis für Wartungsfreundlichkeit und Hochverfügbarkeit. Wir unterscheiden zwischen der manuellen Live Migration (für geplante Wartung) und dem Automatic Failover (für ungeplante Hardware-Ausfälle). Ein Senior Admin sorgt dafür, dass alle VMs auf Shared Storage (Artikel 685) liegen und dass das Cluster-Netzwerk genug Bandbreite für schnelle Schwenks bietet, um die Downtime im Sekundenbereich zu halten.

# 1. Live Migration vs. Automatic Failover

Geplant vs. Ungeplant.

1. Live Migration (Artikel 672):
   • Szenario: Admin will Host A neustarten.
   • Vorgang: Die laufende VM wird via Netzwerk auf Host B geschoben.
   • Ergebnis: Null Downtime. Die Applikation läuft unterbrechungsfrei weiter.
2. Automatic Failover (HA):
   • Szenario: Host A stirbt (Stromausfall).
   • Vorgang: Der Cluster-Manager (CRM) bemerkt den Ausfall und startet die VM auf Host B neu.
   • Ergebnis: Minimale Downtime (Bootzeit der VM). Datenstand ist der Zeitpunkt des Crashs (falls Shared Storage genutzt wurde).

# 2. Voraussetzungen für einen sauberen Schwenk

Die Checkliste der Resilienz.

Damit der Failover gelingt, müssen beide Hosts “Zwillinge” sein:

• Storage: Die VM-ID muss auf dem Ziel-Host den gleichen Speicherpfad finden (z.B. /mnt/pve/nas-images).
• Networking: Die virtuelle Bridge (z.B. vmbr10) muss auf dem Ziel-Host identisch konfiguriert sein (VLANs, MTU).
• CPU: Wenn Host A eine moderne Intel-CPU hat und Host B eine alte, schlägt die Live-Migration fehl (Artikel 666).

# 3. Deep Dive: HA-Gruppen & Failover-Domains

Die Schwenk-Logik steuern.

Sie wollen nicht, dass Ihre wichtigste Datenbank auf den schwächsten Ersatz-Server schwenkt.

1. Datacenter -> HA -> Groups.
2. Erstellen Sie eine Gruppe High-Perf-Nodes.
3. Wählen Sie nur die leistungsstarken Hosts aus.
4. Priority: Geben Sie Knoten A die Priorität 10 und Knoten B die Priorität 5.

• Wirkung: Der Cluster versucht die VM immer auf dem leistungsstärksten verfügbaren Knoten zu halten.

# 4. Day-2 Operations: Failover-Testing

Den Ernstfall proben.

Ein Failover-Plan, der nie getestet wurde, ist wertlos.

• Aktion: Schalten Sie am Wochenende einen Proxmox-Knoten hart aus (Stecker ziehen oder IPMI-Power-Off).
• Beobachtung:
  • Wie lange dauert es, bis der Cluster den Ausfall bemerkt? (Standard: ~60 Sek).
  • Starten alle VMs in der richtigen Reihenfolge (Artikel 676)?
  • Gibt es IP-Konflikte nach dem Neustart?

# 5. Troubleshooting & “War Stories”

Wenn der Schwenk hängen bleibt.

# Top 3 Fehlerbilder

1. Symptom: VM schwenkt um, hat aber keine Netzwerkverbindung.

   • Ursache: Das VLAN am Switch-Port des Ziel-Hosts ist nicht erlaubt.
   • Lösung: Switch-Konfiguration (Trunks) vereinheitlichen.

2. Symptom: “Migration failed: local resources detected”.

   • Ursache: Die VM hat eine durchgereichte USB-Festplatte (Artikel 674) oder eine ISO aus dem lokalen Storage gemountet.
   • Fix: Lokale Medien vor der Migration “unmounten”.

3. Symptom: Failover-Schleife (VM startet und crasht sofort wieder).

   • Lösung: Max Restart Wert in den HA-Settings begrenzen, um den Host nicht zu überlasten.

# “War Story”: Der “Storage-Timeout” Teufel

Ein Admin betrieb seinen Cluster mit einem instabilen NFS-NAS. Das Ereignis: Das NAS hatte einen kurzen Hänger (10 Sekunden). Das Ergebnis: Alle 3 Proxmox-Knoten dachten gleichzeitig, ihre Disks seien weg. Da HA aktiv war, versuchten alle Knoten gleichzeitig, die VMs der “vermeintlich toten” Nachbarn zu übernehmen. Dies führte zu einem massiven I/O-Sturm auf das NAS, sobald es wieder da war, was das NAS erneut in die Knie zwang. Lehre: HA benötigt ein felsenfestes Storage-Backend. Nutzen Sie für HA-Workloads lieber Ceph (Artikel 687) oder Multipath-iSCSI, um kurzzeitige Netzschwankungen abzufangen.

# 6. Monitoring & Reporting

Statistiken der Verfügbarkeit.

# Downtime Analyse (Shell)

# Zeigt den zeitlichen Ablauf des letzten Failovers
journalctl -u pve-ha-crm --since "today"

• KPI: Recovery Time. Messen Sie die Zeit vom Host-Crash bis zum ping -t Erfolg der VM.

# 7. Fazit & Empfehlung

VM Migration und Failover sind die Kerndisziplinen des Datacenters.

• Empfehlung: Automatisieren Sie die Lastverteilung mit dem Proxmox DRS-Skript (Community), wenn Sie viele Knoten haben.
• Wichtig: Sorgen Sie für eine redundante Stromversorgung der Switche. Wenn der Storage-Switch stirbt, hilft Ihnen auch der beste HA-Cluster nicht mehr.

# Anhang: Cheatsheet (Failover Parameter)

# Referenzen

• Proxmox VE: High Availability Documentation
• PfSense/OPNsense: CARP vs Cluster HA
• Veeam: Disaster Recovery Planning Guide