Proxmox Storage-Migration im laufenden Betrieb — ohne Downtime

Ein Anruf am Dienstagmorgen: der SSD-Pool eines produktiven Proxmox-Hosts wirft SMART-Warnungen. Zwei Laufwerke stehen im Pre-Fail, die ERP-Datenbank und der Terminalserver laufen darauf. Ein klassisches Wartungsfenster ist frühestens in zehn Tagen möglich — und selbst das nur mit sechs Stunden Ausfall. Genau für dieses Szenario existiert in Proxmox VE die Live-Storage-Migration: qm move-disk verschiebt VM-Disks zwischen zwei beliebigen Storages, ohne dass die virtuelle Maschine auch nur eine Sekunde offline geht.

In diesem Artikel zeigen wir den Ablauf am Beispiel einer Migration von einem alternden SSD-ZFS-Pool auf einen neuen NVMe-Pool und ergänzen den Sonderfall Ceph zu ZFS. Wir gehen auf die Mechanik unter der Haube ein, sprechen Throughput-Steuerung an und beschreiben, was im Fehlerfall zu tun ist.

Wie die Live-Migration in Proxmox technisch funktioniert

qm move-disk nutzt intern den QEMU-Mechanismus drive-mirror. Sobald der Befehl gestartet wird, hängt QEMU einen zweiten Backing-Store an die laufende VM. Alle neuen Schreibvorgänge werden auf beide Storages gespiegelt, parallel läuft im Hintergrund ein Full-Copy des bestehenden Inhalts vom Quell- auf das Ziel-Storage. Ist die Kopie abgeschlossen und beide Seiten sind synchron, wechselt QEMU den aktiven Backing-Store auf das Ziel und trennt das Quell-Volume ab.

Für die VM ist der Vorgang transparent: keine Pause, keine RAM-Migration, keine Netzwerktrennung. Was Sie im Gast-System sehen, ist maximal eine leicht erhöhte I/O-Latenz während des Mirror-Betriebs, sofern Quell- oder Ziel-Storage bereits stark ausgelastet sind.

Wichtig ist die Unterscheidung zwischen online und offline:

• Online-Modus (VM läuft): drive-mirror, transparent, keine Downtime.
• Offline-Modus (VM ausgeschaltet): einfacher Block-Copy, deutlich schneller weil kein Sync-Overhead, aber eben mit Ausfall.

Für Produktivsysteme kommt in aller Regel nur der Online-Modus in Frage. Der Offline-Modus lohnt sich für Templates, kalte Snapshots oder Testsysteme.

Ausgangslage: SSD-Pool mit SMART-Warnung

In unserem Beispiel läuft ein Proxmox VE 8.4-Host mit folgender Storage-Konfiguration:

Storage-ID	Backend	Devices	Zustand
ssd-pool-01	ZFS RAID10	4x 3,84TB SATA-SSD	2 Devices in Pre-Fail
nvme-pool-01	ZFS RAID10	4x 3,84TB Enterprise-NVMe	neu, leer
backup-nfs	NFS	TrueNAS-Share	für PBS-Snapshots

Auf ssd-pool-01 liegen acht VMs, darunter der ERP-Server (VMID 101, 500 GB Systemdisk + 2 TB Datendisk), zwei Windows-Terminalserver und ein Linux-Fileserver. Ziel ist die vollständige Migration auf nvme-pool-01 innerhalb der Geschäftszeiten, ohne Rückfragen bei den Anwendern.

Vorab ein Blick auf den Pool-Zustand:

zpool status ssd-pool-01
# pool: ssd-pool-01
# state: DEGRADED
# status: One or more devices has experienced an error resulting in data corruption.
# action: Restore the file in question if possible. Otherwise restore the entire pool from backup.

smartctl -a /dev/sdb | grep -E "Reallocated|Wear_Leveling|Media_Wearout"

Solange der Pool noch nicht auf FAULTED steht, funktioniert die Live-Migration problemlos — die Lesevorgänge werden von den gesunden Mirror-Partnern bedient.

Der Migrationsbefehl im Detail

Der zentrale Befehl ist schlicht:

qm move-disk 101 scsi0 nvme-pool-01 --delete 1

Was hier passiert:

• 101 ist die VMID
• scsi0 ist der zu migrierende Disk-Slot
• nvme-pool-01 ist das Ziel-Storage
• --delete 1 entfernt das Quell-Volume nach erfolgreichem Sync

Für die zweite Disk der VM analog:

qm move-disk 101 scsi1 nvme-pool-01 --delete 1

Über die Web-UI erreichen Sie dieselbe Funktion unter VM > Hardware > Hard Disk > Disk Action > Move Storage. Wir bevorzugen für den Regelfall die CLI, weil sie sich skripten lässt und die Ausgabe im Log klar dokumentiert.

Fortschritt lässt sich live verfolgen — der Befehl blockt so lange, bis die Migration abgeschlossen ist, und gibt regelmäßig einen Prozentwert aus. Für Screen-detached-Betrieb bei großen Volumes empfiehlt sich tmux oder ein at-Job.

Throughput steuern und Produktion schützen

Die Achillesferse jeder Live-Migration ist die zusätzliche Last auf Quell- und Ziel-Storage. Wenn der Quell-Pool ohnehin schon degraded ist, kann eine unlimitierte Kopie die restlichen Devices in die Sättigung treiben und Latenz-Spikes für die Anwender erzeugen.

Proxmox erlaubt die Begrenzung der Migrationsrate über den Parameter --bwlimit (in KiB/s):

qm move-disk 101 scsi1 nvme-pool-01 --delete 1 --bwlimit 200000

200000 KiB/s entsprechen rund 200 MB/s — ein typischer Wert, der auf einem NVMe-Ziel gut verkraftbar ist und dennoch die Quell-SSDs nicht abwürgt. In unseren Kundenprojekten sehen wir typischerweise die besten Ergebnisse, wenn wir die Migration während der Kernarbeitszeit auf 100-200 MB/s drosseln und erst nach 18 Uhr auf volle Geschwindigkeit hochziehen.

Ein zusätzlicher Blick auf iostat, zpool iostat und die Grafana-Dashboards des Hosts während der Migration ist Pflicht. Wer den Vorgang blind startet und dann nicht mehr hinschaut, riskiert genau die Störung, die er vermeiden wollte.

Sonderfall: Ceph zu ZFS

Ein etwas komplexerer Fall ist die Migration weg von einem Ceph-Cluster hin zu einem lokalen ZFS-Storage — etwa im Rahmen einer Konsolidierung von drei auf zwei Hosts, bei der Ceph seine Quorum-Voraussetzung verliert. Der Befehl selbst bleibt identisch:

qm move-disk 205 scsi0 local-zfs --delete 1

Zu beachten sind aber zwei Punkte: Erstens ist Ceph als Cluster-Storage in aller Regel deutlich langsamer im sequentiellen Read als ein lokales NVMe-ZFS, die Migration wird also durch die Quelle limitiert. Zweitens müssen Sie sicherstellen, dass die VM nach der Migration nicht mehr HA-managed ist, wenn das Ziel-Storage lokal (nicht shared) ist — sonst schlägt der HA-Manager beim nächsten Node-Ausfall fehl. Prüfen Sie:

ha-manager config
ha-manager remove vm:205

Für den umgekehrten Weg (ZFS zu Ceph) gilt dasselbe Verfahren — hier ist der Ceph-Cluster typischerweise das schnellere Ziel, sofern er ausreichend OSDs bietet.

Rollback, Fehlerfall und Log-Verifikation

Was passiert, wenn der Zielspeicher während der Migration voll läuft oder eine NVMe ausfällt? qm move-disk bricht in diesem Fall ab, das Ziel-Volume wird verworfen und die VM läuft unverändert auf dem Quell-Storage weiter. Ein echtes Rollback ist nicht nötig, weil die Quelle bis zum erfolgreichen Switch nie verändert wird.

Wenn Sie nachträglich merken, dass eine Migration doch nicht optimal war (z. B. Ziel-Pool zu klein dimensioniert), führen Sie einfach eine erneute qm move-disk in die Gegenrichtung aus — ebenfalls live.

Zur Verifikation lohnt sich immer der Blick ins Task-Log des Web-UI (Datacenter > Node > Task History) sowie in /var/log/pve/tasks/. Ein erfolgreicher Move-Task endet mit:

transferred 2.00 TiB of 2.00 TiB (100.00%)
TASK OK

Ergänzend prüfen wir nach jeder Migration in einem Kundenprojekt:

• qm config <vmid> — zeigt das neue Storage-Backend
• zfs list bzw. rbd ls — Volume nicht mehr auf Quelle vorhanden
• Read-/Write-Test in der VM (fio oder Anwendungstest)
• SMART-Werte des Ziel-Pools als Baseline dokumentieren

Fazit

Live-Storage-Migration ist in Proxmox VE ein produktionsreifes Werkzeug, das ungeplante Wartungsfenster in vielen Fällen komplett vermeidet. Voraussetzung ist ausreichende Kapazität auf dem Ziel-Storage, ein sauber überwachter I/O-Pfad und die Disziplin, --bwlimit sinnvoll zu setzen. Wer die Mechanik einmal verstanden hat, betrachtet SMART-Warnungen und Storage-Wechsel nicht mehr als Krisenprojekt, sondern als reguläre Betriebstätigkeit.

DATAZONE unterstützt Sie bei der Planung, Umsetzung und Überwachung solcher Migrationen — vom Sizing des neuen NVMe-Pools über die Migrationsstrategie bis zur laufenden Monitoring-Integration. Wir kombinieren dabei unsere Erfahrung aus Proxmox-Beratung und TrueNAS-Storage, damit Ihre Virtualisierungsplattform auch nach dem Hardware-Wechsel stabil bleibt. Sprechen Sie uns an — kurzes Vorgespräch und Bestandsaufnahme sind kostenfrei: Kontakt.