Live Migration im Cluster

[plurgi95]

Hallo zusammen,

ich versuche aktuell, eine VM (ID 190111) live auf einen anderen Node zu migrieren. Leider bricht der Vorgang direkt zu Beginn ab. Eine Live-Migration (ohne Downtime) ist für diese VM zwingend erforderlich.

Was mich an dem Log sehr irritiert: Die Festplatten werden als `.qcow2` erkannt, aber bei der `disk-2` (TPM) bricht er mit einem LVM-Fehler ab.

Hier ist das Log:

2026-03-24 08:54:40 starting migration of VM 190111 to node 'pve01' (10.10.190.3)
2026-03-24 08:54:40 found local disk 'data:vm-190111-disk-0.qcow2' (attached)
2026-03-24 08:54:40 found local disk 'data:vm-190111-disk-1.qcow2' (attached)
2026-03-24 08:54:40 found generated disk 'data:vm-190111-disk-2.qcow2' (in current VM config)
2026-03-24 08:54:40 copying local disk images
2026-03-24 08:54:40 ERROR: storage migration for 'data:vm-190111-disk-2.qcow2' to storage 'data' failed - cannot migrate from storage type 'lvm' to 'lvm'
2026-03-24 08:54:40 aborting phase 1 - cleanup resources
2026-03-24 08:54:40 ERROR: migration aborted (duration 00:00:01): storage migration for 'data:vm-190111-disk-2.qcow2' to storage 'data' failed - cannot migrate from storage type 'lvm' to 'lvm'
TASK ERROR: migration aborted

Meine Fragen dazu:
1. Warum wirft Proxmox hier einen LVM-zu-LVM Fehler, obwohl es sich laut Log um `.qcow2` Dateien handelt?
2. Wie kann ich das Problem mit dieser "generated disk" beheben, damit die Live-Migration erfolgreich und ohne Ausfallzeit durchläuft?

bei Disk 2 Handelt es sich um die TPM Partition diese muss ja auch Verschoben werden bei einem Serverausfall..

und ein Weiteres Problem ist Offline VMs lassen sich nicht Migireren auf einen Anderen Host wenn dass Ziel Storage ein anderen namen Trägt.


Vielen Dank im Voraus für eure Unterstützung!

 

[LnxBil]

Warum wirft Proxmox hier einen LVM-zu-LVM Fehler, obwohl es sich laut Log um `.qcow2` Dateien handelt?

Weil du snapshot-chaining bei LVM an hast.

Disk 2 Handelt es sich um die TPM Partition diese muss ja auch Verschoben werden bei einem Serverausfall..

Wie soll das gehen wenn das Storage wie in der Meldung erscheint ein lokales Storage ist?

Poste mal bitte deine Storage konfiguration. Das local hier impliziert, dass es kein cluster Storage ist und somit der Quell der Probleme.

und ein Weiteres Problem ist Offline VMs lassen sich nicht Migireren auf einen Anderen Host wenn dass Ziel Storage ein anderen namen Trägt.

Wie einen anderen Namen? In einem Cluster sollte man ein Cluster-Storage verwenden, bei dem nichts übertragen werden muss. Alles andere ist mist und erzeugt genau solche Fehler wie hier.

 

[plurgi95]

Weil du snapshot-chaining bei LVM an hast.

Ah okay, dass wollen wir ja Deaktiviert haben deswegen wollen wir hier die VMs erstmal von VM02 auf VM03 verschieben um dass LVM Storage Lokal neu Anzubinden.

Wie soll das gehen wenn das Storage wie in der Meldung erscheint ein lokales Storage ist?

Poste mal bitte deine Storage konfiguration. Das local hier impliziert, dass es kein cluster Storage ist und somit der Quell der Probleme.

Ja Aktuell haben wir noch kein Shared Cluster Storage angebunden, Dafür müssen wir Erst unsere ESXI Hosts alle Migriert haben.
Für den Zweck haben wir uns 3 PVE Hosts fertig gemacht mit Je 6x 3,2TB NVMe SAS im HW-Raid 5

Auf 2 der 3 Hosts haben wir aber leider beim einrichten dieses snapshot-chaining aktiviert welches immer mal wieder zu Problemen führt.

Wie einen anderen Namen? In einem Cluster sollte man ein Cluster-Storage verwenden, bei dem nichts übertragen werden muss. Alles andere ist mist und erzeugt genau solche Fehler wie hier.

Auf PVE01 & PVE02 heißt dass Local Storage "data" und auf PVE03 "storage" um auf PVE03 dass Snapshot-Chaining zu deaktivieren.

Hier einmal die Config.

Der PVE03 wird dann noch wieder auf LVM umgestellt sobald PVE01 und PVE02 Bereinigt sind von der snapshot-chain

 

[plurgi95]

 

[Johannes S]

Kurze Verständnisfrage: Seid ihr zwingend auf HW-RAID angewiesen (weil ihr sonst z.B. nicht die nötige Kapazität habt)? Falls nicht, würde ich empfehlen auf ZFS und Storage-replication nutzen, das reduziert die Migrationszeiten deutlich und erlaubt eine Art Pseudo-HA (1), bis ihr auf euren shared Storage migriert habt. Man könnte außerdem überlegen aus euren drei Knoten samt lokalen Platten einen Ceph-Cluster zu bauen, damit hätte ihr richtigen shared Storage ohne Datenverlust. Aber: Sowohl Ceph als auch ZFS und HW-Raid zusammen sind problematisch. Zu ZFS hat @Falk R. allerdings angemerkt, dass wenn man weiß, was man tut und bestimmte Dinge beachtet es trotzdem mit HW-Raid zusammen geht, für Ceph weiß ich nicht, wie es da ausschaut.

Wichtig bei ZFS: Dass dann bitte NICHT in RAIDZ (entspricht HW RAID5) nutzen: https://forum.proxmox.com/threads/fabu-can-i-use-zfs-raidz-for-my-vms.159923/

(1) Pseudo, weil bei einen Ausfall es zu einen kleinen Datenverlust kommt: https://pve.proxmox.com/wiki/Storage_Replication

 

[LnxBil]

Ja Aktuell haben wir noch kein Shared Cluster Storage angebunden, Dafür müssen wir Erst unsere ESXI Hosts alle Migriert haben.

Ah .. okay. Gut, dann sind die ganzen Fehler verständlich und nicht zu beheben. Man kann keine VM von einem Storage auf ein anderes migrieren und gleichzeitig die Snapshots behalten.

Wie @Johannes S bereits gesagt hat solltet ihr zuerst mal ein shared Storage haben, dann sollten die Fehler auch schon weggehen. Wenn ihr jetzt in der Testphase auch auf Storage-HA verzichten könnt (könnt ihr ja anscheinen, denn aktuell habt ihr es ja auch nicht), dann wäre ein dedizierter iSCSI oder NFS-Server auch eine Möglichkeit.

 

[plurgi95]

Wir sind auf HW-Raid angewiesen da wir mit ZFS deutliche Performance probleme unserer Systeme hatten.
Wir hatten 2 monate lang ZFS im einsatz und bei unserem Anwendungsfall mit Bis zu 30 Windows VMs (Je Host) mit Datenbanken und Terminal Systemen leider nur Probleme gehabt

 

[plurgi95]

Ah .. okay. Gut, dann sind die ganzen Fehler verständlich und nicht zu beheben. Man kann keine VM von einem Storage auf ein anderes migrieren und gleichzeitig die Snapshots behalten.

Wie @Johannes S bereits gesagt hat solltet ihr zuerst mal ein shared Storage haben, dann sollten die Fehler auch schon weggehen. Wenn ihr jetzt in der Testphase auch auf Storage-HA verzichten könnt (könnt ihr ja anscheinen, denn aktuell habt ihr es ja auch nicht), dann wäre ein dedizierter iSCSI oder NFS-Server auch eine Möglichkeit.

Snapshots sind ja keine Angelegt. dass ist eine Saubere neue VM mit TPM Laufwerk.
Ohne TPM Laufwerk lässt sich die VM Mühelos verschieben..

 

[Johannes S]

Wenn die Migration nur eine einmalige Aktion ist, geht auch immer der Weg einmal ein Backup zu machen und wiederherzustellen. Ist natürlich ein wenig von hinten durch die Brust ins Auge, aber zusammen mit dem live-restore-Feature von PBS sollte sich eine Downtime sich so sehr kurz halten lassen.

 

[plurgi95]

Wenn die Migration nur eine einmalige Aktion ist, geht auch immer der Weg einmal ein Backup zu machen und wiederherzustellen. Ist natürlich ein wenig von hinten durch die Brust ins Auge, aber zusammen mit dem live-restore-Feature von PBS sollte sich eine Downtime sich so sehr kurz halten lassen.

Da Müssen wir die Migrations Aktion dann wohl auf die Wartungen Verschieben, weil ohne das TPM laufwerk gehts ja dann entfernen wir diese verschieben die VMS und Ändern die Storages..

Weil Über Backups LiveRestore bei laufenden Kundensystemen auf denen Gearbeitet wird ist denkbar ungünstig.
Dafür müssen die Kunden dann ja Offline sein.

 

[Johannes S]

Ich sehe das auch nur als Notlösung, wenn sonst nichts funktioniert. Aber live-restore hat halt den Witz, dass die wiederhergestellte VM direkt wieder zum Arbeiten zur Verfügung steht. Als erstes wird der Kram restored, den es zum Starten braucht der Rest dann nachgeladen: https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_live_restore

Ist natürlich nicht so performant bis alles restored wurde, aber eben mit sehr kurzer Downtime verbunden. Ist also als Notlösung besser als das ganze restore abwarten zu müssen

 

[plurgi95]

Ich sehe das auch nur als Notlösung, wenn sonst nichts funktioniert. Aber live-restore hat halt den Witz, dass die wiederhergestellte VM direkt wieder zum Arbeiten zur Verfügung steht. Als erstes wird der Kram restored, den es zum Starten braucht der Rest dann nachgeladen: https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_live_restore

Ist natürlich nicht so performant bis alles restored wurde, aber eben mit sehr kurzer Downtime verbunden. Ist also als Notlösung besser als das ganze restore abwarten zu müssen

Ja aber der Letzte sicherungs stand währe dann gestern um 21 uhr. da wir nur Täglich sichern und nicht Stündlich. Daher ist dieser weg wirklich nur im Worstcase oder dierekt morgens vor arbeitsbeginn sinnvoll.

 

[Johannes S]

Ja aber der Letzte sicherungs stand währe dann gestern um 21 uhr. da wir nur Täglich sichern und nicht Stündlich. Daher ist dieser weg wirklich nur im Worstcase oder dierekt morgens vor arbeitsbeginn sinnvoll.

Naja, es hindert euch ja niemand daran, vor der "Migration" noch eine Extrasicherung zu machen. Und das dirty-bitmap-Feature von qemu sorgt ja dafür, dass inkrementelle Backup im Regelfall nicht allzulange dauern sollten. Man braucht für den live-restore halt den ProxmoxBackupServer, aber der ist ja schnell aufgesetzt und braucht nicht zwingend eine Subskription, wenn man sonst ein anderes Backuptool nutzt.

 

[Falk R.]

Wir sind auf HW-Raid angewiesen da wir mit ZFS deutliche Performance probleme unserer Systeme hatten.
Wir hatten 2 monate lang ZFS im einsatz und bei unserem Anwendungsfall mit Bis zu 30 Windows VMs (Je Host) mit Datenbanken und Terminal Systemen leider nur Probleme gehabt

Das klingt nach RaidZ. Mit Mirror läuft es immer flott.
RaidZ sollte man nicht für VMs nutzen.
Der HWRaid ist aber nur so schnell mit RAID5/6 wenn die Batterie OK ist.
Wenn die mal kaputt geht, bist du mit der Performance unter RaidZ.

Was Johannes angemerkt hat, solange du ein Single vdev hast, kannst du HWRaid mit ZFS nutzen.
Bei Ceph niemals HW RAID nutzen.