Erfahrungen mit LVM (thick) + iSCSI Multipath (Pure Storage) und Volume-Chain Snapshots unter Proxmox VE 9

Sep 11, 2025
21
10
3
Hallo zusammen,

wir setzen seit Kurzem Proxmox VE 9 produktiv ein und haben dabei eine Pure Storage-Anbindung über iSCSI mit Multipath.
Die VM-Disks liegen auf klassischem LVM (thick provisioning) innerhalb mehrerer Volume-Group auf dem Pure-Target.

Nach der Migration hat sich herausgestellt, dass die neue Funktion
„Snapshots als Volume-Chain auf LVM-thick“ aktuell noch als Technology Preview gilt – leider wurde uns das erst nach der Implementierung / nach dem Kauf bewusst.

Daher meine Fragen an die Community:
  1. Hat jemand von euch mit einer ähnlichen Konstellation
    (LVM thick + Multipath + iSCSI-Backend / Pure Storage o. ä.)
    bereits positive oder negative Erfahrungen mit den neuen Snapshots gemacht?
  2. Sind bei euch Backups und Live-Migrationen stabil geblieben, wenn Snapshots aktiviert waren?
  3. Gibt es eventuell Empfehlungen oder bekannte Stolperfallen, auf die man achten sollte?
Wir möchten einschätzen, ob sich das Feature auch im produktiven Umfeld schon bewährt hat oder ob ihr eher noch auf klassische Mechanismen (z. B. externe Storage-Snapshots) setzt.

Vielen Dank schon mal für eure Erfahrungswerte und Tipps!
(System: Proxmox VE 9.x – Cluster mit Multipath-iSCSI auf Pure Storage FlashArray, LVM thick Volumes)

Beste Grüße
Jan
 
Hallo zusammen,

wir setzen seit Kurzem Proxmox VE 9 produktiv ein und haben dabei eine Pure Storage-Anbindung über iSCSI mit Multipath.
Die VM-Disks liegen auf klassischem LVM (thick provisioning) innerhalb mehrerer Volume-Group auf dem Pure-Target.

Nach der Migration hat sich herausgestellt, dass die neue Funktion
„Snapshots als Volume-Chain auf LVM-thick“ aktuell noch als Technology Preview gilt – leider wurde uns das erst nach der Implementierung / nach dem Kauf bewusst.

Daher meine Fragen an die Community:
  1. Hat jemand von euch mit einer ähnlichen Konstellation
    (LVM thick + Multipath + iSCSI-Backend / Pure Storage o. ä.)
    bereits positive oder negative Erfahrungen mit den neuen Snapshots gemacht?
  2. Sind bei euch Backups und Live-Migrationen stabil geblieben, wenn Snapshots aktiviert waren?
  3. Gibt es eventuell Empfehlungen oder bekannte Stolperfallen, auf die man achten sollte?
Wir möchten einschätzen, ob sich das Feature auch im produktiven Umfeld schon bewährt hat oder ob ihr eher noch auf klassische Mechanismen (z. B. externe Storage-Snapshots) setzt.

Vielen Dank schon mal für eure Erfahrungswerte und Tipps!
(System: Proxmox VE 9.x – Cluster mit Multipath-iSCSI auf Pure Storage FlashArray, LVM thick Volumes)

Beste Grüße
Jan
Hi Jan,

ich sehe das aus einer anderen Sicht. Seit vielen jahren predige ich, Snapshots nicht zu nutzen (außer vCenter aus Gründen) sondern Backups.
Du kannst doch einfach mit dem PBS Snapshot Backups machen und wenn du ein Snapshot von einer VM machst für ein Applikationsupdate wobei dir einen Konfigdatei kaputt geht, musst du beim Snapshot zurückrollen und neu beginnen. Bei einem Backup kannst du auch einzelne Dateien restoren.
Außerdem kannst du Backups viel länger liegen lassen ohne Impact, denn Snapshots wachsen gern, wenn die länger liegen bleiben.

Das Setup mit iSCSI/FC habe ich bei vielen Kunden, die von vSphere umgestiegen sind und alle machen Backups statt Snapshots.
Alles reine Gewohnheit. ;)
 
  • Like
Reactions: Johannes S
Hi Falk,
verstehe ich absolut – wir nutzen den PBS ebenfalls und fahren grundsätzlich auch den Backup-Ansatz. Es gibt bei uns aber Szenarien, in denen ein Snapshot trotzdem sinnvoll bzw. notwendig ist.

Beispielsweise bei größeren Updates (z. B. SAP auf mehreren Maschinen gleichzeitig): da liegt es oft gar nicht in unserer Hand, eine defekte Datei oder fehlerhafte Konfiguration gezielt zu identifizieren. Auch der Zeitfaktor spielt da eine Rolle – ich kann meinem Chef schlecht erklären, dass wir erst einmal vier Stunden down sind, weil ich sechs Server einzeln aus dem Backup wiederherstellen muss, falls der Fehler nicht sofort auffindbar ist.

Klar, es gibt Testszenarien – aber wie immer steckt der Teufel im Detail. Mit einem Snapshot kann ich im Worst Case einfach „Kommando zurück“ sagen und bin in zehn Minuten wieder betriebsbereit. Danach kann man in Ruhe analysieren und sauber weitermachen.

Backups sind also bei uns Standard, aber Snapshots bleiben für genau solche Rollback-Szenarien ein wertvolles Werkzeug. Wir sind dabei aber sehr vorsichtig und fahren aktuell ein größeres Update unter VMware zu Ende.

Viele Grüße
Jan
 
  • Like
Reactions: Johannes S
Gerade bei SAP würde ich niemals auf die Backups verzichten, aber das handhabt jeder etwas anders.
Wenn wirklich alle 6 Server defekt sein sollten, müsste man die parallel per Live Restore zurückholen. Da braucht man auf jeden Fall einen Full Flash PBS.

Aber gerade bei SAP hat man das Update vorher getestet und ich durfte auch schon einmal aus einem Backup was ich eine Stunde vorher gemacht hatte einen ganzen Ordner zurückholen, damit man den Snapshot nicht zurückrollen muss. Das SAP Team des Kunden war sehr glücklich, dass ich vorher noch einmal Backups gemacht habe.
Den Ansatz fahre ich auch seit mindestens 10 Jahren mit vSphere und Veeam.
 
  • Like
Reactions: Johannes S
cool and the vdisk itself is also created by this plugin?

Correct, it creates a disk and then presents it over iSCSI and then logins to the iSCSI target.

So you'd no longer need to create disks or resize them on the Pure, then login to the Proxmox to change it there as well. You pretty much can do everything in Proxmox. So the snapshots, disk creation, deletion, and so on is all handled by the plugin.
 
  • Like
Reactions: j.gelissen
similar to the blockbridge appliance plugin or the integraded zfs-over-iscsi plugin. this way is always better than the lvm-thick way. really great
 
Correct, it creates a disk and then presents it over iSCSI and then logins to the iSCSI target.

So you'd no longer need to create disks or resize them on the Pure, then login to the Proxmox to change it there as well. You pretty much can do everything in Proxmox. So the snapshots, disk creation, deletion, and so on is all handled by the plugin.
Thanks everyone for the detailed info and experiences — really interesting, especially about the PureStorage plugin.
To be honest, after reading a bit more about it, I don’t really feel confident implementing the plugin afterwards in my existing setup.
My cluster is running in production, and I’d rather not introduce a non-official storage plugin at this stage, even though it looks like a very clean solution technically.
Maybe I’ll spin up a test environment later to try it out.
Still, thanks for pointing it out — I actually didn’t know such an integration existed!
 
Gerade bei SAP würde ich niemals auf die Backups verzichten, aber das handhabt jeder etwas anders.
Wenn wirklich alle 6 Server defekt sein sollten, müsste man die parallel per Live Restore zurückholen. Da braucht man auf jeden Fall einen Full Flash PBS.

Aber gerade bei SAP hat man das Update vorher getestet und ich durfte auch schon einmal aus einem Backup was ich eine Stunde vorher gemacht hatte einen ganzen Ordner zurückholen, damit man den Snapshot nicht zurückrollen muss. Das SAP Team des Kunden war sehr glücklich, dass ich vorher noch einmal Backups gemacht habe.
Den Ansatz fahre ich auch seit mindestens 10 Jahren mit vSphere und Veeam.
Ehrlich gesagt bereue ich gerade ein bisschen den Wechsel von VMware zu Proxmox.
Ich hatte von gestern auf heute einen Snapshot liegen lassen und wollte diesen eigentlich nur löschen – vor allem, weil unsere virtualisierte Windows-11-VM extrem langsam geworden ist.

Dabei bin ich direkt in einen Fehler geraten, der die Maschine komplett gesperrt hat. Ich musste sie erst manuell über die CLI entsperren, um sie anschließend herunterzufahren und den Snapshot löschen zu können.

Ziemlich unschönes Erlebnis, wenn man gerade einfach nur schnell etwas aufräumen wollte. Zum Glück war das eine Testmaschine.
 
Ehrlich gesagt bereue ich gerade ein bisschen den Wechsel von VMware zu Proxmox.
Ich hatte von gestern auf heute einen Snapshot liegen lassen und wollte diesen eigentlich nur löschen – vor allem, weil unsere virtualisierte Windows-11-VM extrem langsam geworden ist.

Dabei bin ich direkt in einen Fehler geraten, der die Maschine komplett gesperrt hat. Ich musste sie erst manuell über die CLI entsperren, um sie anschließend herunterzufahren und den Snapshot löschen zu können.

Ziemlich unschönes Erlebnis, wenn man gerade einfach nur schnell etwas aufräumen wollte. Zum Glück war das eine Testmaschine.
Was genau hast du denn da gemacht? Ich habe in 20 Jahren Virtualisierung nur vSphere VMs herunter fahren müssen, wenn der Datastore 100% voll war um Snapshots zu löschen. Bei HyperV oder Proxmox habe ich soetwas noch nie gesehen. Ein Unlock per CLI kann manchmal nötig sein, aber dann ist schon vorher etwas anderes schief gelaufen.
Gern mehr Infos was für ein Speicher und warum du herunter fahren musstest, zum Snapshot löschen. Ich kann mir keinen Grund herleiten.
 
  • Like
Reactions: Johannes S
Bei Nutzung eines unbekannten System muss man immer erst die Dos und Donts lernen. Mein könnte jetzt gehässig sein und schreiben "mit dem purestorage plugin wäre es nicht passiert", aber deine Meinung dahingehend ist nachvollziehbar. Trotzdem ist es ein wirklich untypisches Verhalten PVEs. War die VM auch auf dem LVM storage mit aktiviertem Volumen-chain?
 
ich sehe das aus einer anderen Sicht. Seit vielen jahren predige ich, Snapshots nicht zu nutzen (außer vCenter aus Gründen) sondern Backups.
Du kannst doch einfach mit dem PBS Snapshot Backups machen und wenn du ein Snapshot von einer VM machst für ein Applikationsupdate wobei dir einen Konfigdatei kaputt geht, musst du beim Snapshot zurückrollen und neu beginnen. Bei einem Backup kannst du auch einzelne Dateien restoren.
Nö, snapshot loop mounten und alle einzelnen Dateien ww. rauskopierbar ohne voll zurückzusetzen.
 
Nö, snapshot loop mounten und alle einzelnen Dateien ww. rauskopierbar ohne voll zurückzusetzen.
Funktioniert das denn bei jeden Storage-Backend? Ich meine mich zu erinnern, dass z.B. qcow-Snapshots (etwa auf NFS-Freigaben) sich nicht loop mounten lassen.
 
Wegen diesem komischem qcow2 nbd modul mount, wo sich anschliessend das modul nicht wieder entladen läßt ...,
--> auf .raw umgestiegen, ist eh einfacher und geht für vm & lxc, zudem machen wir den mount direkt auf fileserver, kannst natürlich auch auf pve dir erstellen und jenes image von nfs darauf mounten.
 
Was genau hast du denn da gemacht? Ich habe in 20 Jahren Virtualisierung nur vSphere VMs herunter fahren müssen, wenn der Datastore 100% voll war um Snapshots zu löschen. Bei HyperV oder Proxmox habe ich soetwas noch nie gesehen. Ein Unlock per CLI kann manchmal nötig sein, aber dann ist schon vorher etwas anderes schief gelaufen.
Gern mehr Infos was für ein Speicher und warum du herunter fahren musstest, zum Snapshot löschen. Ich kann mir keinen Grund herleiten.
PureStorage -> LUN -> Multipath -> LVM Thick -> qcow2 -> Snapshot Funktion

Da ist ein bisschen mehr passiert:
  • Windows 10-Kiste virtualisiert
  • von VMware zu Proxmox migriert
  • danach TPM und UEFI hinzugefügt
  • Snapshot angelegt (ohne RAM) — bin mir nicht mehr sicher, ob der Snapshot eventuell noch vor dem Hinzufügen von TPM/UEFI erstellt wurde
  • über Nacht so stehen gelassen
  • in der Nacht hat dann der PBS-Backup-Job ein Backup erstellt
  • heute wegen Performance-Problemen CPU und RAM geändert
  • dabei bemerkt, dass noch ein Snapshot aktiv war
  • beim Entfernen kam die Meldung, dass die VM während der Snapshot-Entfernung blockiert wird
  • Entfernung abgebrochen — keine Fehlermeldung, aber VM blieb gesperrt
  • VM anschließend per CLI entsperrt und heruntergefahren
  • Snapshot ließ sich danach beim zweiten Versuch löschen, allerdings nur im ausgeschalteten Zustand
 
Last edited:
Bei Nutzung eines unbekannten System muss man immer erst die Dos und Donts lernen. Mein könnte jetzt gehässig sein und schreiben "mit dem purestorage plugin wäre es nicht passiert", aber deine Meinung dahingehend ist nachvollziehbar. Trotzdem ist es ein wirklich untypisches Verhalten PVEs. War die VM auch auf dem LVM storage mit aktiviertem Volumen-chain?
Wir nutzen ausschließlich LVM-Thick über Pure Multipath.

Ich vermute, das Problem lag eher daran, dass ich recht viel an der Hardwarekonfiguration gedreht habe, weil eine virtualisierte Windows 11-VM extrem langsam war – inklusive Wechsel auf TPM und UEFI. Die Maschine hatte fast durchgehend 100 % CPU-Auslastung.

Gestern habe ich dann den Snapshot gestartet und heute bemerkt, dass beim Löschen etwas schiefgelaufen ist: Er hat die VM gesperrt, aber den Löschvorgang nicht beendet. Die VM blieb in einem „laufenden, aber gesperrten“ Zustand hängen.

Ich habe sie schließlich per CLI entsperrt und einen Hard-Stop durchgeführt.

Interessanterweise konnte ich anschließend den Snapshot problemlos löschen – und danach auch die VM selbst.

Die CLI zeigt jetzt 0 KB belegt auf dem LVM an, also scheint alles wieder sauber zu sein.

Grundsätzlich gibt mir das aber kein gutes Gefühl und mit einem GitHub Skript auf einer laufenden Umgebung wo 30 VMs laufen auch nicht wirklich wenn man sich nicht zu 100 Prozent damit auskennt und damit startet