Snapshots auf Shared LVM: was FC- und iSCSI-Umgebungen jetzt können

/01Worum es geht — und worum nicht

Ein Mittelstandscluster, der von VMware kommt, bringt in der Regel sein SAN mit: ein Array mit Restlaufzeit, angebunden per Fibre Channel oder iSCSI, bisher mit VMFS formatiert. In Proxmox VE wird daraus ein Shared-LVM-Storage: eine Volume Group auf dem LUN, die alle Knoten sehen, mit einem Logical Volume je VM-Disk. Das funktioniert seit Jahren stabil, mit Live-Migration, HA und allem, was ein Cluster braucht — nur Snapshots gab es nicht. Die Dokumentation ist dazu deutlich: Native LVM-Snapshots bringen „significant input/output (I/O) penalties and unexpected, dangerous behavior when running out of pre-allocated space", und LVM-thin ist auf geteiltem Storage nicht zulässig.

Seit Proxmox VE 9.0 schließt der Mechanismus „snapshots as volume chains" diese Lücke. Er nutzt laut Dokumentation ausschließlich die Fähigkeit von qcow2, mehrere Volumes in einer Backing-Kette zu schichten — nicht die Snapshot-Funktion von qcow2 selbst — und ist damit „vendor-agnostic support for snapshots on any storage system that supports block storage". Der Array-Hersteller spielt keine Rolle, ein Storage-Plugin ist nicht nötig.

Was dieser Artikel nicht wiederholt: die Mechanik der Kette, die unabhängigen Leistungsmessungen und die Kapazitätsrechnung. Das steht in SAN-Snapshots in Proxmox: eine Kette, kein Storage-Snapshot. Hier geht es um die Betriebsseite: Was kann eine FC- oder iSCSI-Umgebung damit im Alltag tun, was nicht, und wie kommt sie dahin.

/02Was sich von 9.0 bis 9.2 geändert hat

Die Funktion kam mit Proxmox VE 9.0 am 5. August 2025 als Technologie-Vorschau. Proxmox VE 9.1 vom 19. November 2025 brachte laut Roadmap die Ablage des vTPM-Zustands im qcow2-Format — vorher waren Windows-VMs mit virtuellem TPM von Snapshots auf der Kette ausgeschlossen, weil der TPM-Zustand ein eigenes Volume ohne Kettenfähigkeit war. Für einen Mittelstandscluster, in dem Windows 11 und Windows Server 2025 den Großteil der Gäste stellen, war das der Unterschied zwischen „geht theoretisch" und „geht bei uns".

Proxmox VE 9.2 vom 21. Mai 2026 führt in den Release Notes den Eintrag „Fix cluster-locking behavior when performing snapshot operations on a shared LVM storage". Das klingt nach einer Fußnote, ist aber der Punkt, an dem die Funktion für Cluster erst belastbar wird: Jeder Snapshot legt ein neues Logical Volume an, und im geteilten Betrieb darf zu jedem Zeitpunkt nur ein Knoten die LVM-Metadaten der Volume Group ändern. Ein Fehler in dieser Sperre ist auf einem Einzelknoten unsichtbar und im Drei-Knoten-Cluster ein Metadatenkonflikt. Wer die Funktion auf 9.0 oder 9.1 getestet und verworfen hat, hat einen anderen Stand getestet.

Was sich nicht geändert hat: der Status. Die Dokumentation zum LVM-Backend sagt mit Stand September 2026 weiterhin „Snapshots as volume chains are currently a technology preview in Proxmox VE", und die Roadmap führt als offenes Ziel, die Funktion auf LVM-thick, Directory, NFS und CIFS aus der Vorschau zu entlassen — einschließlich der Online-Entfernung des obersten Snapshots.

/03Welche Arbeitsabläufe jetzt möglich sind

Vier Abläufe, die in VMware-Umgebungen selbstverständlich waren und auf Shared LVM bisher fehlten, sind mit 9.2 in der Oberfläche und auf der Kommandozeile verfügbar.

Rücksprungpunkt vor einem Update

Der häufigste Fall: Snapshot vor dem Patchday, Update einspielen, prüfen, Snapshot entfernen oder zurückrollen. Das war der Ablauf, den Terminalserver-Betreiber am meisten vermisst haben — der Fall vom September-Patchday zeigt, warum ein Rücksprungpunkt in Minuten etwas anderes ist als eine Rücksicherung in Stunden.

# Vor dem Update
qm snapshot 140 vor-patchday-2026-10 --description "Windows Server 2025, KB-Stand 30.09."

# Kette ansehen
qm listsnapshot 140
# `-> vor-patchday-2026-10   2026-10-01 07:55:02   Windows Server 2025, KB-Stand 30.09.
#     `-> current            You are here!

# Fall A: Update in Ordnung -> Snapshot entfernen (VM aus, siehe Abschnitt 7)
qm delsnapshot 140 vor-patchday-2026-10

# Fall B: Update defekt -> zurueckrollen
qm rollback 140 vor-patchday-2026-10

Mehrere Stände hintereinander

Die Kette erlaubt mehrere Snapshots je VM — etwa vor dem Betriebssystem-Update, vor dem Anwendungs-Update, vor der Datenbankmigration. Jeder Schritt ist einzeln rücknehmbar. Der Preis: Jede Schicht ist ein volles Logical Volume, und jede Schicht verlängert den Leseweg. Drei Stände sind ein Arbeitsablauf, dreißig sind ein Kapazitätsproblem.

Snapshot mit laufender VM

Der Snapshot wird bei laufender VM angelegt; der Gast läuft während des Vorgangs weiter. Für Windows-Gäste mit vTPM gilt das seit 9.2 ebenfalls, nachdem 9.1 den TPM-Zustand in qcow2 gebracht hat. Was nicht im Snapshot liegt, ist der Arbeitsspeicher — dazu Abschnitt 7.

Snapshot-Zustand in Backup und Migration

Eine VM mit Snapshots auf Shared LVM lässt sich weiterhin per Live-Migration zwischen den Knoten verschieben, weil die Kette auf dem gemeinsamen LUN liegt und kein Knoten sie kopieren muss. Die Roadmap nennt als offenes Ziel, die verbleibende Einschränkung für die Migration von VMs mit Snapshots auf lokalem Storage aufzuheben — auf geteiltem Storage stellt sich die Frage nicht.

/04Welche VMFS-Gewohnheiten nicht übertragbar sind

Wer aus der vSphere-Welt kommt, hat Snapshot-Gewohnheiten, die auf der Volume-Kette nicht funktionieren — nicht, weil Proxmox schlechter wäre, sondern weil der Mechanismus ein anderer ist.

Die wichtigste Umgewöhnung ist die dritte Zeile. In vSphere wächst eine Delta-Disk mit den Änderungen; in Proxmox reserviert LVM bei jedem Snapshot sofort die volle Größe. Ein 500-GB-Volume mit drei Snapshots belegt auf LVM-Ebene das Vierfache — was das Array daraus tatsächlich belegt, hängt an dessen Thin Provisioning. Die Rechnung steht im Schwesterartikel; hier genügt die Regel: Vor dem Einschalten die freie Kapazität der Volume Group gegen die Zahl gleichzeitiger Snapshots rechnen, nicht danach.

/05Bestehende Umgebung umstellen: Storage, Volumes, Autoaktivierung

Drei Schritte, in dieser Reihenfolge.

1. Parameter am Storage setzen

# /etc/pve/storage.cfg — bestehender Shared-LVM-Eintrag, eine Zeile kommt dazu
lvm: san-fc01
    vgname vg-san-fc01
    shared 1
    content images
    snapshot-as-volume-chain 1

# Alternativ ueber die Kommandozeile
pvesm set san-fc01 --snapshot-as-volume-chain 1
pvesm status --storage san-fc01

Die Dokumentation sagt ausdrücklich, dass die Einstellung nur neu angelegte Volumes betrifft. Bestehende VMs laufen unverändert weiter — ohne Snapshots.

2. Bestehende Disks überführen

Eine vorhandene raw-Disk auf dem SAN bekommt keine Kette. Der Weg ist, die Disk auf denselben Storage in das qcow2-basierte Format zu verschieben; dabei entsteht ein neues Volume, das die Kette unterstützt.

# Disk der VM 140 auf demselben Storage in qcow2 ueberfuehren (VM kann laufen)
qm disk move 140 scsi0 san-fc01 --format qcow2 --delete 1

# Kontrolle: Format des neuen Volumes
qm config 140 | grep scsi0
# scsi0: san-fc01:vm-140-disk-1.qcow2,size=500G,...

Das ist ein vollständiger Kopiervorgang je Disk über das SAN — bei fünfzig VMs mit zusammen zwanzig Terabyte ein Projekt über mehrere Wartungsfenster, nicht ein Nachmittag. Und es ist der Punkt, an dem die Entscheidung fällt, welche VMs die Kette überhaupt bekommen sollen: Die Datenbank mit hoher Schreiblast vielleicht nicht, der Terminalserver und die Anwendungsserver schon.

3. LVM-Autoaktivierung abschalten

Seit Proxmox VE 9 werden neue Gast-Volumes ohne LVM-Autoaktivierung angelegt; für bestehende Volumes empfiehlt die Upgrade-Anleitung auf Shared Storage ausdrücklich das mitgelieferte Skript /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation. Mit der Kette wird das wichtiger, nicht unwichtiger: Jede Schicht ist ein weiteres LV, und ein Knoten, der beim Start alle LVs der Volume Group aktiviert, aktiviert auch die Schichten von VMs, die gerade auf einem anderen Knoten laufen. Wer das Upgrade von 8 auf 9 hinter sich hat, hat den Schritt idealerweise schon erledigt — die Upgrade-Anleitung führt ihn unter den bekannten Bruchstellen.

/06Multipath, Discard und die Rolle des Arrays

Die Kette setzt unterhalb von LVM an und ist der Transportart gleichgültig — Fibre Channel, iSCSI oder NVMe-oF ändern an der Mechanik nichts. Was sich unterscheidet, ist die Anbindung darunter, und dort liegen die Fehler, die als „Snapshot-Problem" gemeldet werden und keines sind.

Multipath muss vor dem ersten Snapshot sauber stehen: ein Gerät je LUN, alle Pfade aktiv, kein Pfad, der beim Failover eine Sekunde hängt. Ein Snapshot legt ein neues LV an und ändert Metadaten — trifft das auf einen Pfadwechsel, ist die Sperre im Cluster die Stelle, an der es klemmt. Die Grundeinrichtung mit multipath.conf, wwid und den Filterregeln in lvm.conf steht in Proxmox-Cluster mit Fibre-Channel-SAN.

Discard entscheidet, ob gelöschte Snapshots Platz zurückgeben. Die Dokumentation formuliert es als Bedingung: „For efficient support of snapshot-as-volume-chain, the backing storage must support thin-provisioning and discard. Each snapshot will appear to use the full volume size on the PVE side, but the actual space usage on the underlying storage will be smaller if those requirements are met." Ein Array ohne Thin Provisioning — ältere Einstiegsklassen, manche thick angelegte LUNs auf sonst thin-fähigen Arrays — macht jeden Snapshot dauerhaft teuer. Das lässt sich vorher prüfen:

# Meldet das Blockgeraet Discard-Faehigkeit?
lsblk -D /dev/mapper/mpatha
# NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
# mpatha        0        4K       4G        0
# DISC-GRAN 0B und DISC-MAX 0B heissen: kein Discard, Snapshots geben nichts zurueck

# Auf VM-Ebene Discard durchreichen
qm set 140 --scsi0 san-fc01:vm-140-disk-1.qcow2,discard=on,ssd=1

/07Container, RAM-Zustand und andere Grenzen

Die Tabelle der Storage-Funktionen in der Proxmox-Dokumentation führt für LVM bei Snapshots „yes" mit der Fußnote „Since Proxmox VE 9, snapshots as a volume chain available for VMs". Container stehen dort nicht. Wer LXC-Container auf dem SAN betreibt, hat für sie weiterhin keine Snapshots auf Shared LVM — für Container mit Snapshot-Bedarf bleibt lokaler ZFS-Storage oder Ceph der Weg.

Der Arbeitsspeicher der VM ist nicht Teil der Kette; der Snapshot hält den Disk-Zustand fest. Für den Anwendungsfall „Rücksprungpunkt vor Update" ist das gleichgültig — die VM startet nach dem Rollback ohnehin neu. Für den Anwendungsfall „Zustand einer laufenden Anwendung einfrieren und später exakt dort weitermachen", den vSphere mit Memory-Snapshots bedient, ist es das nicht.

Der oberste Snapshot lässt sich bei laufender VM nicht entfernen; die Roadmap führt die Online-Entfernung als offenen Punkt. Praktisch heißt das: Der Ablauf „Snapshot vor dem Update, Update in Ordnung, Snapshot bei laufender VM wieder weg" braucht für den letzten Schritt ein kurzes Wartungsfenster — oder man lässt den Snapshot bis zum nächsten geplanten Neustart stehen, was den Kapazitätsbedarf entsprechend verlängert. Linked Clones auf Basis der Kette nennt die Funktionstabelle für LVM ebenfalls nicht; Vollklone gehen.

Und der Status bleibt Technologie-Vorschau. Das ist kein Warnhinweis aus Vorsicht: Zwischen 9.0 und 9.2 hat sich das Verhalten der Funktion — vTPM, Cluster-Sperre — spürbar geändert, und die Roadmap kündigt weitere Änderungen an. Wer sie produktiv einsetzt, fährt einen Teil der Plattform, den der Hersteller noch nicht in die volle Unterstützung entlassen hat.

/08Wo es hakt: Betriebsfragen vor dem Einschalten

Vier Fragen, die vor dem Setzen des Parameters beantwortet sein sollten.

Wer räumt auf?

Ein Snapshot, den niemand entfernt, ist auf der Kette teurer als auf VMFS: volle LV-Größe, längerer Leseweg, Wartungsfenster zum Entfernen. Ohne Regel — „Snapshots älter als sieben Tage werden im nächsten Wartungsfenster entfernt" — wächst die Kette, bis das LUN voll ist. Das ist keine Formsache, sondern der häufigste Betriebsfehler, den wir bei Snapshot-Einführungen sehen, auf jeder Plattform.

Was sagt das Monitoring?

Freie Kapazität der Volume Group, Zahl der LVs je VM, Alter der Snapshots — das gehört als Kennzahl mit Schwellenwert ins Monitoring, bevor der erste Snapshot fällt. pvesm status zeigt die Belegung, qm listsnapshot je VM die Kette; ein Skript, das beides täglich einsammelt, ist in einer Stunde geschrieben.

Welche VMs bekommen die Kette?

Die Überführung der Disks aus Abschnitt 5 ist der Moment der Auswahl. Datenbanken mit hoher zufälliger Schreiblast profitieren am wenigsten und zahlen am meisten — für sie bleibt der Array-Snapshot oder die Sicherung der bessere Rücksprungpunkt. Terminalserver, Anwendungsserver, Domänencontroller vor dem Patchday: Das ist der Einsatzbereich.

Ist das Array-Snapshot-Feature nicht ohnehin da?

Die meisten Enterprise-Arrays können LUN-Snapshots im Controller, ohne Kette, ohne Leistungsverlust — aber LUN-granular statt VM-granular und ohne Anbindung an die Proxmox-Oberfläche. Für „ganzes SAN vor der Migration sichern" ist das der bessere Weg; für „diese eine VM vor dem Update" die Kette. Beides zusammen ist kein Widerspruch.

/09Wann Sie die Funktion einschalten sollten — und wann nicht

Die Funktion ist mit 9.2 gut genug, um den Rücksprungpunkt vor dem Patchday auf einem FC- oder iSCSI-SAN abzubilden — den Anwendungsfall, der VMware-Umsteigern am meisten gefehlt hat. Sie ist nicht gut genug, um alle Snapshot-Gewohnheiten aus vSphere unbesehen zu übernehmen.

Einschalten, wenn

• Der Cluster auf 9.2 steht: Die korrigierte Cluster-Sperre ist die Voraussetzung, nicht eine Verbesserung.
• Das Array Thin Provisioning und Discard beherrscht und lsblk -D das bestätigt — sonst gibt kein gelöschter Snapshot Platz zurück.
• Es einen Aufräumplan und ein Monitoring der Volume Group gibt, bevor der erste Snapshot fällt.
• Die Kette auf unkritische VMs begrenzt beginnt und erst nach einigen Wochen Beobachtung auf den Rest ausgedehnt wird.

Nicht einschalten, wenn

• Eine interne oder externe Vorgabe Technologie-Vorschau-Funktionen im Produktivbetrieb ausschließt: Dann ist die Antwort gegeben, unabhängig von der Technik.
• Das Array kein Thin Provisioning kann: Jeder Snapshot bleibt dauerhaft in voller Größe belegt, und das LUN ist schneller voll, als der Aufräumplan greift.
• Der Bedarf eigentlich „Sicherung" heißt: Ein Snapshot auf demselben LUN ist kein Backup. Der Proxmox Backup Server deckt den Rücksprungpunkt vor dem Update ebenfalls ab — langsamer im Rollback, aber ohne Kette und außerhalb des Arrays.
• Die Hardware-Erneuerung ohnehin ansteht: Dann ist die Frage „SAN behalten oder auf Ceph umbauen" wichtiger als die Frage nach der Kette — Ceph bringt Snapshots ohne Zwischenschicht mit.

Unsere Praxis-Linie: Für VMware-Umsteiger mit SAN ist die Kette der Grund, warum das Argument „auf Proxmox gibt es keine Snapshots auf unserem Storage" seit 9.2 nicht mehr zieht. Produktiv fahren wir sie dort, wo der Rücksprungpunkt vor dem Patchday den Betrieb trägt, mit Aufräumregel und Monitoring — und nicht als Ersatz für Array-Snapshots oder Backup.

/10Häufige Fragen