Proxmox VM Live-Migration ohne Shared Storage: wann es wirklich geht und wo die Grenzen liegen

Shared Storage ist in Proxmox-Clustern seit Jahren das Standardversprechen für saubere Live-Migration: Ceph, NFS, iSCSI oder GlusterFS unter allen Nodes, und eine VM wechselt in Sekunden den Host, ohne dass irgendjemand im Backend auch nur einen Takt verpasst. In der Praxis ist das aber lange nicht in jedem Mittelstandscluster so. Zwei- oder Drei-Node-Umgebungen mit lokalen ZFS-Pools auf schnellen NVMe-Laufwerken sind nach wie vor sehr verbreitet — oft deshalb, weil Ceph für die Workload-Größe überdimensioniert wäre oder weil die Latenzen eines dedizierten SAN keinen Mehrwert für die Fachanwendungen bringen.

Die Frage, die uns dann regelmäßig erreicht: Kann eine Proxmox-VM auch ohne Shared Storage live migriert werden? Die kurze Antwort lautet ja. Die lange Antwort hat Bedingungen, Grenzen und Entscheidungsgrundlagen — und darum geht es in diesem Artikel.

Proxmox Live-Migration ohne Shared Storage: was Proxmox eigentlich macht

Startet man eine Migration zwischen zwei Nodes, bei denen die Ziel-Storage-ID nicht Shared Storage ist, erkennt Proxmox das automatisch. Statt nur den RAM-Zustand zu übertragen, wird parallel eine Storage-Migration eingeleitet: QEMU hängt am Ziel-Node ein neues Backing-Device an und spiegelt die Disk-Blöcke live. Intern ist das die gleiche drive-mirror-Mechanik, die auch beim lokalen qm move-disk zum Einsatz kommt — nur eben über die Grenzen zweier Nodes hinweg.

Für den Admin fühlt sich der Befehl erstmal gleich an:

qm migrate 101 pve-node02 --online --with-local-disks

Das Flag --with-local-disks ist dabei das Entscheidende. Ohne diesen Zusatz würde Proxmox die Migration verweigern, weil die Disk nicht auf einem gemeinsam zugreifbaren Storage liegt. Mit dem Flag startet die VM-Migration und die Disk-Replikation gleichzeitig: RAM-Pages gehen klassisch via Pre-Copy, Disk-Blöcke gehen via Mirror. Beide Prozesse laufen parallel, bis am Ende der kurze Switchover kommt.

Was in der Doku gerne mal untergeht: Der Vorgang hat drei Phasen, nicht zwei. Die erste Phase ist die eigentliche Disk-Kopie, die zweite die RAM-Übertragung, die dritte der Switchover. Je größer die Disk, desto länger Phase eins — und desto höher das Risiko, dass sich in dieser Zeit sowohl auf Disk als auch im RAM genug geändert hat, dass das finale Delta länger pausiert als gewünscht.

Wann die Live-Migration ohne Shared Storage realistisch funktioniert

Aus unseren Projekten lassen sich ein paar klare Muster ableiten, bei denen das Verfahren wirklich sauber läuft:

• Kleine bis mittelgroße VMs mit Disks bis etwa 500 GB und RAM-Werten im einstelligen GB-Bereich wandern mit sehr überschaubarem Zeitaufwand.
• Niedrige bis moderate Schreib-Last während des Migrationsfensters. Eine ERP-Datenbank unter Volllast ist der problematischste Kandidat, ein Terminalserver mittags der entspannteste.
• Schnelle Netzwerkverbindung zwischen den Nodes, idealerweise 10 GbE dediziert für Migration und Replikation. 1 GbE funktioniert technisch, führt aber bei größeren Disks schnell zu Migrationszeiten jenseits der 30 Minuten.
• Gleiches Storage-Backend auf Quell- und Ziel-Node. ZFS zu ZFS ist der Standardfall. Von LVM-Thin zu ZFS funktioniert ebenfalls, benötigt aber mehr Zeit, weil kein Blocksize-Alignment möglich ist.

Problematisch wird es, sobald sehr große VM-Disks im Spiel sind — also 2 TB und mehr — und gleichzeitig hohe I/O-Last anliegt. Nicht, weil Proxmox das technisch nicht könnte, sondern weil die Mirror-Phase so lange dauert, dass das Delta nie wirklich konvergiert. In solchen Fällen verlängert sich die Switchover-Pause spürbar, oder die Migration schlägt sogar fehl.

ZFS-Replikation als Beschleuniger: der Trick, den man kennen sollte

Hier liegt der Hebel, der aus einer zähen Migration eine entspannte Angelegenheit macht. Wenn beide Nodes ZFS als lokales Storage verwenden, kann Proxmox eine asynchrone Replikation zwischen den Pools einrichten — über die GUI unter “Replication” oder per CLI mit pvesr. Die Replikation läuft im Hintergrund in konfigurierbaren Intervallen, zum Beispiel alle 15 Minuten, und überträgt nur die ZFS-Snapshot-Deltas zum Ziel-Node.

Das Ergebnis: Startet man später eine Live-Migration, muss Proxmox nicht die komplette Disk kopieren, sondern nur die Blöcke, die sich seit dem letzten Replikations-Snapshot geändert haben. Statt mehrerer hundert Gigabyte wandern dann nur noch wenige Gigabyte, und die Migration dauert statt 30 Minuten vielleicht noch zwei bis drei Minuten.

Diese Kombination — ZFS-Replikation plus Live-Migration — ist aus unserer Sicht der sinnvollste Weg für Zwei- und Drei-Node-Cluster ohne SAN. Mehr dazu steht im Artikel Proxmox-Replikation zwischen zwei Standorten, der die Mechanik und die Einrichtung ausführlich beschreibt.

Was bei der Replikation zu bedenken ist

Replikation ist kein Backup. Sie überträgt alles, was im Snapshot steht, inklusive versehentlich gelöschter Dateien oder korrumpierter Datenbanken. Für Datensicherung bleibt der Proxmox Backup Server die richtige Wahl — Replikation läuft daneben, nicht statt. Außerdem schreibt die Replikation regelmäßig Snapshots auf beiden Seiten, was Pool-Platz und ARC belastet. Bei stark schreibintensiven VMs und knappem Pool-Platz ist das ein Thema, das vor dem Rollout realistisch durchgerechnet werden muss.

Netzwerk-Voraussetzungen in der Praxis

Ein eigenes Migrationsnetz zahlt sich bei lokalen Storages doppelt aus: Es trennt den Mirror-Traffic sauber vom VM-Produktivverkehr, und es verhindert, dass eine Migration den Durchsatz für andere Services einbricht. 10 GbE auf dedizierten NICs mit eigenem VLAN ist in unseren Projekten der Standard, 25 GbE und 100 GbE kommen bei größeren Clustern dazu. Was man vermeiden sollte: Migration über das normale Management-Netz von 1 GbE laufen zu lassen, weil die Mirror-Phase dann je nach Disk-Größe zur Geduldsprobe wird.

Die Migrations-Bandbreite lässt sich im Datacenter unter “Options -> Migration Settings” oder per /etc/pve/datacenter.cfg begrenzen, falls man den Traffic bewusst drosseln möchte, um Produktion nicht zu beeinträchtigen. Ein Beispielwert von 500 MByte/s auf einer 10-GbE-Strecke ist in laufenden Umgebungen ein guter Startpunkt. Mehr Hintergrund zum Clusternetz-Design steht im Artikel zum Proxmox Cluster-Netzwerkdesign.

Downtime-Erwartung: ehrlich, nicht geschönt

Zeroes-Downtime ist bei dieser Variante nicht realistisch. In der Praxis sehen wir Switchover-Pausen, die je nach VM und Load zwischen wenigen Sekunden und knapp einer Minute liegen. Für die meisten Fachanwendungen ist das unkritisch — RDP-Sessions reconnecten, SMB-Shares überleben kurze Pausen in der Regel ohne Datenverlust, Webanwendungen und Datenbanken reagieren mit einer kurzen Verzögerung.

Was dagegen nicht funktioniert: Echtzeit-Workloads wie VoIP-Gateways, Telefonanlagen oder Prozessleittechnik ohne Puffer. Für solche Dienste ist entweder Shared Storage mit sauberer Live-Migration unter einer Sekunde Pause die bessere Wahl, oder eine Cluster-Lösung auf Anwendungsebene, die die Migration komplett wegabstrahiert.

Realistische Erwartungen in drei Szenarien

Szenario	Disk	Netzwerk	ZFS-Replikation	Realistische Pause
Terminalserver 200 GB	ZFS lokal	10 GbE dediziert	aktiv, 15-min-Intervall	wenige Sekunden
Fileserver 1 TB	ZFS lokal	10 GbE dediziert	aktiv, stündlich	10 bis 30 Sekunden
ERP-DB 2 TB, hohe Last	LVM-Thin lokal	1 GbE	keine Replikation	30 Sekunden oder Migration fehlgeschlagen

Die Werte sind Erfahrungswerte, keine Benchmarks. Jede Umgebung bringt eigene Variablen mit, und wir testen bei Produktivmigrationen grundsätzlich einmal vorher mit einer unkritischen VM auf dem gleichen Weg.

Grenzen, die man kennen sollte

Live-Migration ohne Shared Storage ist kein Allheilmittel. Drei Punkte, bei denen das Verfahren an seine Grenzen stößt:

Thin Provisioning und Overprovisioning. Wenn der Ziel-Pool knapp bemessen ist und die VM-Disk thin provisioniert, kann die Live-Migration mittendrin fehlschlagen, weil der Platzbedarf höher ist als erwartet. Vorher mit zfs list und qm list --full den tatsächlichen Verbrauch gegenchecken.

Snapshots während der Migration. Snapshots, die während einer laufenden Migration erzeugt werden, führen zu inkonsistenten Zuständen und werden von Proxmox zurecht blockiert. Scheduled Snapshots in dieser Zeit also unbedingt pausieren — gerade bei kombinierter PBS-Nutzung ein häufig übersehener Punkt.

Hardware-Features im Durchreichmodus. PCIe-Passthrough, SR-IOV, vGPU oder dedizierte USB-Geräte überleben eine Live-Migration prinzipiell nicht. Wer eine solche VM auf einen anderen Node bekommen will, muss sie vorher kontrolliert herunterfahren.

Entscheidungsrahmen: wann Shared Storage am Ende doch der bessere Weg ist

Es gibt eine klare Grenze, ab der sich eine SAN- oder Hyperconverged-Lösung wie Ceph oder iSCSI auf TrueNAS wirklich lohnt. Grob gesagt: Ab Clustern mit vier oder mehr Nodes, bei Workloads über 10 TB Netto-VM-Daten, bei strikten Downtime-Anforderungen unter fünf Sekunden — oder wenn Replikation den ARC auf den Nodes zu stark belastet. In solchen Umgebungen bauen wir in Kundenprojekten gerne Hybrid-Lösungen: TrueNAS Enterprise mit NVMe-TCP oder iSCSI als zentrales Block-Storage, Proxmox darüber als Hypervisor. Das Zusammenspiel beschreibt der Artikel zum Proxmox-TrueNAS-Plugin mit NVMe-TCP im Detail, und für die Hardware-Seite hilft unser TrueNAS-Konfigurator bei der Auslegung.

Für alle anderen Fälle — also die klassischen Zwei- und Drei-Node-Setups im Mittelstand — ist die Kombination aus lokalen ZFS-Pools und asynchroner Replikation seit Jahren bewährt und in den allermeisten Umgebungen völlig ausreichend. Welche Variante zur eigenen Umgebung passt, lässt sich am besten mit einer kurzen Bestandsaufnahme klären — dazu beraten wir im Rahmen unserer Virtualisierungs-Services oder über den TrueNAS-Support wenn die Storage-Seite dabei relevant wird.

FAQ

Brauche ich für Live-Migration ohne Shared Storage ein Enterprise-Repository oder reicht die Community-Variante?

Die Funktionalität ist in jeder Proxmox-VE-Installation enthalten, unabhängig vom gewählten Repository. Für produktive Umgebungen empfehlen wir das Enterprise-Repository wegen stabilerer Updates und Herstellersupport — die Migration selbst funktioniert in beiden Fällen identisch.

Kann ich zwischen Nodes mit unterschiedlichen Storage-Backends migrieren, etwa von LVM-Thin auf ZFS?

Ja, Proxmox übersetzt die Blöcke beim Mirror-Vorgang automatisch. Es ist allerdings langsamer als ZFS-zu-ZFS-Migration, weil kein Blocksize-Alignment möglich ist und ZFS die Daten beim Empfang neu komprimiert. Für einmalige Konsolidierungen gut machbar, für regelmäßige Migrationen würden wir ein einheitliches Backend empfehlen.

Wie läuft es ab, wenn eine Migration mittendrin abbricht?

Proxmox behält die Quell-VM aktiv, bis der Switchover erfolgreich war. Bricht die Migration vorher ab — etwa durch Netzwerkprobleme oder vollen Ziel-Pool — läuft die VM auf dem Quell-Node ungestört weiter, und am Ziel-Node werden die halben Disk-Teile automatisch aufgeräumt. Rollback-Risiko ist in der Praxis gering.

Funktioniert das auch mit Windows-VMs?

Ja, das Verfahren ist OS-agnostisch. Windows-VMs mit VirtIO-Treibern migrieren genauso sauber wie Linux-Gäste. Bei älteren Windows-Versionen ohne VirtIO lohnt es sich, vorher die Treiber zu aktualisieren — die Switchover-Pause ist dann deutlich kürzer, weil die Netzwerk-Reconnects schneller laufen.

Sollte ich während der Migration den Proxmox Backup Server pausieren?

Scheduled Backups und Snapshots während einer laufenden Migration führen gelegentlich zu Konflikten. Wir pausieren bei größeren Migrationen die Backup-Jobs für die betroffene VM gezielt im PBS-Job oder über das Protection-Flag und reaktivieren sie nach dem Umzug. Für kleine VMs mit wenigen Minuten Migrationsdauer ist das meist nicht nötig.

Was passiert mit der Migration, wenn die VM einen laufenden Snapshot hat?

Snapshots aus dem Proxmox-Snapshot-Menü werden mitwandern, wenn das Ziel-Storage sie unterstützt — also ZFS zu ZFS oder qcow2 zu qcow2. Zwischen inkompatiblen Backends (ZFS zu LVM-Thin ohne qcow2-Zwischenformat) muss der Snapshot vorher gelöscht werden, sonst verweigert Proxmox die Migration mit einer entsprechenden Fehlermeldung.