TrueNAS-Plugin für Proxmox: ZFS over iSCSI, neu verpackt und noch nicht reif

Wer seine Proxmox-Cluster über iSCSI vom NAS mit Storage versorgt, kennt die Routine hinter jeder einzelnen Platte: auf dem TrueNAS ein zvol anlegen, ein Extent darauf bauen, es mit dem Target verknüpfen, den LUN am Knoten anmelden. Und bei jeder Änderung dieselbe Runde durch beide Welten. TrueNAS hat dafür jetzt ein eigenes Plugin veröffentlicht. Die Ankündigung verspricht, Proxmox möge TrueNAS-abgelegte VM-Disks direkt anlegen, snapshoten, vergrößern, migrieren und löschen, ganz ohne manuelle LUN-Verwaltung. Das klingt, als wäre ZFS over iSCSI endlich offiziell. Wir haben den Quellcode gelesen statt die Werbetafel. Stand: 15. September 2026.

Was das Plugin technisch macht

Grundlage dieser Einordnung ist der Source selbst: TrueNASPlugin.pm, rund 290 KB Perl unter GPL-3.0, gepflegt in der TrueNAS-Organisation auf GitHub. Kurz zusammengefasst:

• Steuerungsebene ist die TrueNAS-WebSocket-API. Das Plugin legt je VM-Disk ein zvol unter dem frei wählbaren Dataset an (pool.dataset.create), darauf je ein iSCSI-Extent (iscsi.extent.create) und verknüpft alles mit einem gemeinsamen Target. Die LUN-Nummern vergibt das Plugin selbst, im Proxmox erscheinen die Volumen als vol-<name>-lun<n>.
• Datenebene ist nacktes Standard-iSCSI. Jeder Proxmox-Knoten macht Discovery und Login über iscsiadm und spricht die Platte über das by-path-Gerät an. Multipath ist standardmäßig aktiv, CHAP ist optional. Alternativ gibt es NVMe/TCP, dafür braucht es Proxmox 9.x und TrueNAS SCALE 25.10 oder neuer.
• Snapshots sind echte ZFS-Snapshots auf dem zvol (pool.snapshot.create). Das ist der eigentliche Mehrwert gegenüber NFS und Dateispeichern: Statt eines Snapshot-Vorgangs, der bei großen Platten gern den VM-I/O blockiert, steht hier ein Copy-on-Write-Snapshot auf dem Storage, in Sekunden, Rollback inklusive.

Funktionell ist das die klassische ZFS-over-iSCSI-Architektur mit einer API-Automatisierung obendrauf. Nichts grundlegend Neues, aber sauber gemacht und erstmals herstellergeflegt. Auch Proxmox selbst benutzt die Kategorie inzwischen wörtlich: Der 9.2-Changelog führt TPM-Zustände auf iSCSI- und „ZFS over iSCSI"-Storages als neue Unterstützung auf.

Das Muster ist nicht neu

„ZFS over iSCSI" ist der Begriff eines Community-Plugins, das es seit Jahren gibt: freenas-proxmox unter AGPL-3.0, aktiv gepflegt, zuletzt v4.0.1 (2. September 2026). Beide Plugins existieren heute nebeneinander, eine Nachfolge-Erklärung gibt es von keiner Seite. Immerhin derselbe Zwang für beide: TrueNAS schafft das alte REST-Interface ab, seit SCALE 25.10 zählt nur noch WebSocket.

Was vom Marketing übrig bleibt

Vier Behauptungen der Ankündigung, abgeglichen mit Code und Doku:

1. „Live-Snapshots inklusive RAM." Die Formulierung stimmt nicht. Der RAM wandert nicht in den ZFS-Snapshot, der PVE-Core schreibt ihn als separates vmstate-Volumen (im Plugin wählbar: tn_vmstate_storage shared oder local). Live-Snapshots funktionieren mit Proxmox 9, das ist eine PVE-Funktion und kein TrueNAS-Zauber; die Volume Chains dahinter stehen bei Proxmox noch als Tech-Preview.
2. „Migrate." Das ist die ganz normale Shared-Block-Live-Migration, die funktioniert, weil alle Knoten dieselbe LUN sehen. Eigener Code steckt nicht dahinter. Einzelne Disks zwischen Storages umzuziehen klappt derzeit überhaupt nicht, dafür gibt es ein offenes Issue.
3. „Clones." Vollklone werden Byte für Byte kopiert. ZFS-Clones sind im Code angelegt, PVE umgeht die Clone-Pfade externer Block-Storages aber systematisch, vor „No Fast Clone Support" warnt das eigene Limitations-Dokument.
4. „Löschen ohne Reste." Bleibt ein Clone hängen oder bricht ein Destroy ab, bleiben verwaiste zvols im Dataset zurück und blockieren die VMID-Wiederverwendung. Die Aufräum-Anleitung liefert das Limitations-Dokument gleich mit.

Stand: ordentlich gebaut, offiziell Beta

Das Richtige zuerst: Die Architektur ist sauber, und echte ZFS-Snapshots sind genau das, was NFS-Storages in Proxmox immer gefehlt hat. Ebenso Fakt, und das ist nicht unser Urteil, sondern das des Herstellers:

• Die TrueNAS-Doku sagt wörtlich: active development, not fully tested, Community Edition only, do not use in production workloads. Enterprise-Systeme werden nicht unterstützt.
• Der Issue-Tracker (38 offen am 15.09.2026) enthält unter anderem: „VM disk on NVME-tcp corruption", NVMe-oF-Fehler bei großen I/Os unter Last, Storage nach rund 30 Tagen scheinbar tot wegen abgelaufener API-Session, und der HA-Manager lehnt den Storage als unsupported ab. Dazu CHAP-Probleme auf 25.10 und kaputte Cloud-Init-Erkennung beim Klonen.
• Bus-Faktor 1: Die Wartung läuft im Wesentlichen über einen externen Entwickler (331 von 381 Commits).
• Versionschurn: v2.1.5 (Juni) → v2.1.23-beta3 (11. September). Zwischen dem 24. August und dem 11. September liegen sechs publizierte Builds von alpha33 bis beta3.

Was wir daraus machen

Unsere Produktiv-Stack bleibt, wie er ist: DRBD und LINSTOR als Shared Storage, Vitastor weiterhin im Beobachtungsmodus (Einsatztest), TrueNAS als Datei-Server im Einsatz (Einsatzbericht). Was sich ändert: Wer einen TrueNAS als zentralen Storage stehen hat, Snapshots von der Storage-Seite will und eine Beta verkraftet, hat erstmals einen sauberen Weg ohne LUN-Handarbeit. Bei uns ist das das Homelab, nicht der Industrie-Cluster. Wir testen dort mit dieser Liste:

1. Versionen prüfen: SCALE 25.10 oder neuer, PVE 9.x, Plugin aus dem signierten APT-Repo.
2. Standarddurchlauf: anlegen, Live-Snapshot, Rollback, Resize, Destroy, ohne dass Orphans bleiben.
3. API-Session unter Last kappen: Zeigt sich der 30-Tage-Fall nur über Zeit oder auch bei Verbindungsverlust?
4. vzdump auf LXC (dokumentierte vzdump-Kollision) und Destroy nach abgebrochenem Klon.
5. I/O-Verhalten des Snapshots gegen den NFS-Snapshot messen: Entlastet die CoW-Variante den Gast wirklich?

In Produktion installieren wir nichts, solange zwei Bedingungen nicht erfüllt sind: Der Produktionsvorbehalt muss aus der Doku verschwinden und das Corruption-Issue muss geschlossen sein. Wenn der Hersteller seinen Tracker abarbeitet, ist die Richtung für alle richtig, die ihren Storage ohnehin auf TrueNAS haben.

Weiterführende Quellen

• truenas/truenas-proxmox-plugin auf GitHub, Stand 15.09.2026 (Releases und Issue-Tracker)
• TrueNASPlugin.pm, Quellcode unter GPL-3.0
• TrueNAS Doku: Proxmox VE Storage Plugin mit Requirements und Produktionswarnung
• TheGrandWazoo/freenas-proxmox, Community-Plugin unter AGPL-3.0
• Proxmox VE Roadmap, Volume Chains als Tech-Preview und der Changelog-Beleg zu ZFS over iSCSI