Ausgangslage
Als ich meinen Proxmox-Cluster mit einem iSCSI-Backend auf einem TrueNAS-System verbunden habe, war die Entscheidung schnell gefallen: iSCSI ist der klassische Ansatz für Shared Storage in einer Cluster-Umgebung, taucht in praktisch jedem Proxmox-Tutorial als Erstes auf und ist nah an dem, was man aus der klassischen SAN-Welt kennt. LVM auf iSCSI eingerichtet, funktioniert, VMs laufen, fertig.
Problem
Einige Monate später, mitten in einem völlig anderen Gespräch über eine neue VM, fiel mir eine Sache auf, die ich bis dahin einfach hingenommen hatte: Mein Storage ist thick-provisioned, und ich habe keine Snapshots. Beides klang zunächst wie technisches Kleingedrucktes – bis mir bewusst wurde, was das im Alltag bedeutet:
- Jede VM belegt sofort ihre volle konfigurierte Grösse auf dem Storage, unabhängig davon, wie viel tatsächlich genutzt wird
- Vor riskanten Änderungen (Updates, Config-Experimente) kann ich nicht einfach einen Snapshot ziehen und im Zweifel zurückrollen
Der Grund dafür liegt tiefer, als ich zunächst dachte. iSCSI selbst ist ein reines Block-Protokoll – es kennt keine Snapshot- oder Thin-Provisioning-Befehle. Wenn Proxmox eine LUN über iSCSI einbindet und mit LVM partitioniert, ist das Ergebnis standardmässig thick, weil LVM Blöcke bei der Erstellung reserviert, nicht bei tatsächlichem Schreiben.
Es gibt zwar seit neueren Proxmox-Versionen sogenannte „Snapshots as Volume Chains“, die Snapshots auch auf klassischem iSCSI/LVM ermöglichen – aber die zugrunde liegenden Volumes bleiben dabei weiterhin thick. Und LVM-Thin, die naheliegende Lösung für Thin-Provisioning, hat einen Haken: Es funktioniert über iSCSI nur, wenn die Disk exklusiv einem einzigen Cluster-Node zugeordnet ist. Als Shared Storage über mehrere Nodes hinweg – also genau das, was ich für Live-Migration und HA brauche – ist das nicht vorgesehen. Zu hohes Risiko für Datenkorruption, wenn mehrere Nodes gleichzeitig auf denselben Thin-Pool zugreifen.
Auflösung
Bei der Recherche kristallisierten sich zwei sinnvolle Wege heraus, die beide Cluster-Funktionalität, Snapshots und Thin-Provisioning gleichzeitig bieten:
ZFS over iSCSI. Das ist kein neues Feature, sondern seit Jahren fest in Proxmox eingebaut. Der Unterschied zum klassischen iSCSI+LVM-Ansatz: Proxmox verbindet sich hier direkt per SSH/API mit dem ZFS-Backend (in meinem Fall TrueNAS) und verwaltet die zvols selbst. Da ZFS nativ Snapshots und Sparse-Volumes unterstützt, bekommt man beides „for free“ – vorausgesetzt, das Backend läuft auf ZFS.
NFS statt iSCSI. Der pragmatischere Weg: TrueNAS exportiert stattdessen einen NFS-Share, und Proxmox legt VM-Disks als qcow2-Dateien darauf ab. qcow2 unterstützt Snapshots und Thin-Provisioning von Haus aus – ganz ohne LVM, ohne Multipathing-Konfiguration, ohne Cluster-weites Locking-Gedöns. Ein verbreitetes Missverständnis, dem ich selbst kurz aufgesessen bin: NFS als Shared Storage schränkt Cluster-Funktionen wie Live-Migration oder HA nicht ein – im Gegenteil, NFS ist von Grund auf für gleichzeitigen Zugriff mehrerer Nodes gebaut, was es in mancher Hinsicht sogar unkomplizierter macht als iSCSI+LVM.
Zum Vergleich, wie sich die Optionen unterscheiden:
| Storage-Typ | Cluster-fähig | Snapshots | Thin-Provisioning |
|---|---|---|---|
| iSCSI + LVM (thick) – mein bisheriges Setup | Ja | Nein (ausser Volume-Chains) | Nein |
| iSCSI + LVM-Thin | Nein (nur Single-Node) | Ja | Ja |
| ZFS over iSCSI | Ja | Ja | Ja |
| NFS (qcow2) | Ja | Ja | Ja |
Es gibt inzwischen auch ein natives TrueNAS-Plugin für Proxmox, das die zvol- und iSCSI-Extent-Verwaltung automatisiert und Thin-Provisioning inklusive Live-VM-State-Snapshots (RAM) bietet. Der Hersteller selbst weist allerdings ausdrücklich darauf hin, dass es sich noch in aktiver Entwicklung befindet und nicht für produktive Workloads gedacht ist – für ein Homelab durchaus einen Blick wert, aber (noch) nicht meine erste Wahl für die Migration.
Lessons Learned
- iSCSI+LVM ist der Standard-Tutorial-Weg, aber nicht automatisch der richtige. Die Einschränkungen fallen oft erst auf, wenn man mittendrin steckt.
- „Thin-Provisioning“ und „Cluster-fähig“ schliessen sich bei iSCSI+LVM gegenseitig aus – das ist die eigentliche Kernerkenntnis, die mir gefehlt hat.
- NFS hat ein Imageproblem. Viele assoziieren es fälschlicherweise mit „kein echter Shared Storage“ oder „keine Cluster-Features“ – dabei ist genau das Gegenteil der Fall.
- Storage-Entscheidungen früh im Aufbau eines Homelabs zu treffen, spart später viel Migrationsaufwand. Nachträglich umzustellen bedeutet: pro VM die Disk auf den neuen Storage-Typ verschieben, was zwar möglich, aber eben zusätzlicher Aufwand ist, den man sich mit der richtigen Wahl von Anfang an hätte sparen können.
Fazit
Mein aktuelles Setup funktioniert, ist aber nicht das, was ich mit heutigem Wissen nochmal so aufsetzen würde. Der nächste Schritt ist die Migration auf ZFS over iSCSI oder NFS – dazu mehr in einem der nächsten Beiträge, sobald ich die Umstellung tatsächlich durchgezogen habe. Bis dahin bleibt die Erkenntnis: Manchmal muss man erst ein paar Monate mit einer suboptimalen Lösung leben, bevor einem aus einem ganz anderen Kontext heraus auffällt, was eigentlich das Problem war.