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, aktualisiert am 23. 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 praktische Unterschied zu NFS und Dateispeichern: Hier liegt ein Copy-on-Write-Snapshot auf dem Storage, in Sekunden, Rollback inklusive. Bei großen NFS-Platten blockiert der Snapshot-Vorgang dagegen den VM-I/O über Minuten.

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

Die Architektur ist sauber, und echte ZFS-Snapshots sind genau das, was NFS-Storages in Proxmox gefehlt haben. Der Betriebsstand stammt vom Hersteller selbst:

• Die TrueNAS-Doku sagt wörtlich: active development, not fully tested, Community Edition only, do not use in production workloads. Enterprise-Systeme stehen dort weiterhin auf nicht unterstützt.
• Am 22.09.2026 hat die Wartung 22 Issues an einem Tag geschlossen, die meisten mit Verweis auf v2.1.23-beta3 oder beta4, darunter den Storage-Ausfall nach 30 Tagen, die abgelehnte HA-Prüfung und die kaputte Cloud-Init-Erkennung beim Klonen.
• Geblieben sind 14 offene Issues und 7 offene PRs (Stand 23.09.2026, über die GitHub-API gezählt). Fünf davon betreffen NVMe: „VM disk on NVME-tcp corruption" (#32), NVMe-oF-Fehler bei großen I/Os unter Last (#96), nvmet_tcp-Fehler beim vzdump (#45), NVMe-Dienst, der nach Änderungen neu gestartet werden muss (#12) und Timeout-Warnungen im Storage-API-Call (#4). Die Aufräumwelle hat diese Gruppe unberührt gelassen.
• Bus-Faktor: 39 der letzten 60 Commits trägt ein Mitarbeiter von iXsystems (@truenas.com, @ixsystems.com). Die Masse des Bestands stammt von einem externen Entwickler, 331 von 381 Commits.
• Versionschurn: v2.1.5 (Juni) → v2.1.23-beta5 (23.09.2026). Zwischen dem 24.08. und dem 23.09. liegen acht publizierte Builds von alpha33 bis beta5.

Update 16.09.2026

Ein Tag Tracker, gemessen über die GitHub-API am 16.09.2026:

• Der HA-Fehler sitzt seit v2.1.23-beta4 im Paket. PR #101 wurde am 14.09.2026 gemergt und steckt im Release vom 19.09.2026, das postinst des Tags startet pvedaemon pveproxy pvestatd pve-ha-crm pve-ha-lrm neu, mit TRUENAS_PLUGIN_NO_RESTART=1 als Notausgang. iXsystems markiert beta4 selbst als Pre-Release, die drei Betas davor waren regulär. Wer aus dem APT-Repo installiert, bekommt weiterhin eine ältere Serie, deren Release-Datei den 01.07.2026 und die Version 2.1.17+deb1 nennt.
• Der TrueNAS-26-Patch wurde am 16.09.2026 geschlossen, ohne gemergt zu sein. PR #83 (Host-Whitelist, DH-CHAP, Namespace-Rendering, offen seit 21.07.) ging nach acht Wochen ohne einen einzigen Kommentar zu. Offen bleiben #95 (CHAP auf 25.10, seit 23.08.), #97 (begrenzte API-Proben bei nicht erreichbarem Storage, seit 26.08.), #94 (NVMe/TCP-Portale, seit 17.08.). Dazu #92, ein eigener Fix des Hauptentwicklers vom 06.08. Die ältesten unbearbeiteten Fremd-PRs stammen vom 02.07. und 23.06. Daran messen wir die beiden Bedingungen unten: wie schnell gemergt wird.
• Die Zahl für den 16.09.2026: 31 offene Issues und 6 offene PRs (16.09.2026); die 38 von gestern zählten Issues und Pull Requests zusammen. Dazu Issue #99 (30.08., offen): Das Plugin meldet TESTED_APIVER = 14, TrueNAS 25.10.6 ist auf API-Version 15 und antwortet bei jedem Storage-Aufruf mit einer Deprecation-Warning. Kein Ausfall, aber derselbe Mechanismus, der schon das REST-Interface weggenommen hat. Ein Fremd-Fork (23.08.2026) trägt die CHAP- und Session-Fixes inzwischen extern, wer nicht warten will, patcht selbst.
• Zwei Datumsfelder gehören zusammengelesen: die Doku mit dem Produktionsvorbehalt wurde zuletzt am 26.03.2026 geändert und sagt weiterhin "do not use in production workloads" sowie Enterprise ausdrücklich nicht unterstützt. Die Ankündigung vom 11.09.2026 nennt Enterprise-Support „in active validation and orderable". Das Ältere ist dokumentiert, das Neuere eine Herstellerbehauptung ohne unabhängigen Beleg. Unsere Bedingung hängt an der Doku, nicht am Blog.
• Der HA-Punkt betrifft Proxmox selbst. Derselbe Fehler ist im Proxmox-Plugin von Pure Storage dokumentiert (pve-purestorage-plugin#75). Wir lesen das als strukturelle Eigenschaft fremder Storage-Plugins unter Proxmox: pve-ha-crm und pve-ha-lrm laden Plugin-Typen ausschließlich beim Dienststart. Für unsere Testliste unten heißt das ein sechster Punkt: HA-Manager nach der Installation ausdrücklich prüfen, und zwar vor dem Notfall.

Update 23.09.2026: die Ursachen sind dokumentiert

Wie der Ausfall nach 30 Tagen entstand

Issue #98 hat eine saubere Ursache, die am 22.09.2026 ins Issue geschrieben wurde. Der Broker hielt einen abgelaufenen, aber offenen WebSocket-Key; TrueNAS begrenzt eine Session auf 30 Tage (AA_LEVEL1.max_session_age). Der Liveness-Test rief core.ping auf, und dieser Call ist no_auth_required, sieht eine abgelaufene Session also niemals. Behoben in v2.1.23-beta3, indem der Test jetzt auth.me verlangt und der nächste Aufruf die Session neu aufbaut. Ein Health-Check, der seinen eigenen Fehlermodus nicht sehen kann, lässt sich in jedem System bauen.

Zwei Ursachen für die Korruption, eine liegt bei Proxmox

Issue #96 ist seit dem 28.08.2026 von einem externen Nutzer bis in den Kernel hinein analysiert. nvmet_tcp_ops kennt in mainline Linux kein .get_mdts, NVMe über RDMA und PCIe schon. Der Target advertisiert damit kein maximales Transfer-Size, der Initiator schickt I/Os von 6 bis 32 MiB, der Target antwortet mit sc 0x6. Der Patch liegt seit dem 31.08.2026 in dritter Revision auf der linux-nvme-Liste und trägt ein Reviewed-by von Sagi Grimberg. Gemergt ist er nicht.

Die zweite Hälfte interessiert uns unabhängig von TrueNAS. Proxmox ruft qemu-img convert auf ein Block-Ziel mit dem Default -t unsafe auf. Liegt der Schreibfehler hinter dem Page-Cache, wird er verworfen, und qemu-img beendet sich mit Exit-Code 0. Im Task-Log steht TASK OK, während Daten fehlen. Der Fall ist seit dem 17.09.2026 als Bug 8054 bei Proxmox offen, Status ASSIGNED, zuletzt bewegt am 23.09.2026. Unsere Frage vom ersten Stand ist damit beantwortet: Es braucht einen Block-Storage, der Schreibfehler zurückgibt, dann läuft dieser Weg bei jeder Storage-Klasse dieser Bauart. Bei uns lagert alles auf LINSTOR/DRBD unter PVE 9.2.20, deshalb betrifft uns diese Hälfte direkt.

Die Doku wurde am 23.09. bearbeitet, die Warnung blieb

Die Seite mit dem Produktionsvorbehalt trägt als Bearbeitungsstempel den 23.09.2026, 09:46 EDT (Commit 6375bfff, DOCS-2765). Der Satz do not use in production workloads steht unverändert drin, Enterprise weiterhin auf nicht unterstützt. Der Blogpost vom 11.09.2026, der Enterprise-Appliances einschließt und Support als bestellbar nennt, bleibt als zweite Aussage im Haus.

Ein Fremd-PR in drei Tagen, drei andere warten seit Wochen

PR #110 importiert fremde ZFS-Snapshots in die Gast-Konfiguration, damit qm rollback nicht mehr still an einem neueren Snapshot auf dem zvol scheitert. Er kam am 19.09.2026 herein und wurde am 22.09.2026 um 15:05 UTC von iXsystems gemergt, 2848 Zeilen in zwei Commits. Das Werkzeug heißt truenas-proxmox-manage import-snapshots --dry-run. Unsere Lesart vom 16.09.2026 hält dem nicht stand: #110 war in drei Tagen drin, während #95, #94 und #97 weiterhin seit fünf bis acht Wochen offen sind.

Ein Setup-Beispiel von außerhalb

Am 22.09.2026 ist eine ausführliche Installations-Durchsprache erschienen (VirtualizationHowto). Sie zeigt die Form, in der das Plugin gerade ausprobiert wird: ein einzelner Knoten, TrueNAS als VM mit drei virtuellen Platten, iSCSI als Transport, ohne HA, ohne Last, ohne Löschtest. Die Produktionswarnung der Doku kommt in dem Text nirgends vor. Nützlich ist der Beitrag trotzdem, weil er einen echten Stolperstein dokumentiert: TrueNAS verweigert den Pool, wenn die virtuellen SCSI-Platten keine Seriennummer haben, und Proxmox liefert standardmäßig keine. Abhilfe ist serial=TNBOOT001 pro Platte in /etc/pve/qemu-server/<vmid>.conf.

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 im Rack stehen hat, Snapshots von der Storage-Seite will und eine Beta verkraftet, hat damit einen sauberen Weg ohne LUN-Handarbeit. Bei uns betrifft das das Homelab auf pve7, der Industrie-Cluster bleibt außen vor. 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?
6. HA-Manager nach der Installation prüfen: Gast stoppen und von HA wieder anfahren lassen, ohne Zwischenschritt über die Dienste.
7. Schreibfehler erzwingen: dm-flakey auf einem Ziellaufwerk, dann Klon oder disk move darüber. Meldet der Task TASK OK, obwohl Writes verloren gehen, greift Bug 8054. Dieser Punkt gilt unabhängig vom Plugin und gehört auf jede Testliste, die Block-Ziele prüft.

In Produktion installieren wir nichts, solange zwei Bedingungen offen sind. Erstens muss der Produktionsvorbehalt aus der Doku verschwinden; gemessen wird an der Doku, der Blogpost vom 11.09.2026 ist keine Freigabe. Am 23.09.2026 steht der Satz dort weiterhin, auch nach der Bearbeitung an diesem Tag. Zweitens muss das Corruption-Issue #32 geschlossen sein, mit Bugfix und Reproduktion, zusammen mit den vier weiteren NVMe-Issues der großen I/Os (#96, #45, #12, #4). Der 22.09.2026 hat gezeigt, dass die Wartung an einem Tag 22 Issues abarbeiten kann. Bis die NVMe-Gruppe geschlossen ist, installieren wir das Plugin ausschließlich im Labor.

Weiterführende Quellen

• truenas/truenas-proxmox-plugin auf GitHub, Stand 23.09.2026 (Releases, Issue-Tracker, Pull Requests)
• v2.1.23-beta5 vom 23.09.2026 als aktueller Build; das postinst von v2.1.23-beta4 enthält den HA-Dienstestart
• Issue #96 mit der Kernel-Analyse zu NVMe/TCP und Proxmox Bug 8054 zur stillen Schreibverwerfung, Status ASSIGNED
• PR #110, Import fremder ZFS-Snapshots, gemergt am 22.09.2026
• TrueNASPlugin.pm, Quellcode unter GPL-3.0
• TrueNAS Doku: Proxmox VE Storage Plugin, Bearbeitungsstempel 23.09.2026, mit Requirements und Produktionswarnung
• Ankündigungsblog vom 11.09.2026, die Enterprise-Aussage dazu
• TheGrandWazoo/freenas-proxmox, Community-Plugin unter AGPL-3.0
• Vorgänger-Plugin von WarlockSyno, letzter Commit 02.04.2026
• Setup-Durchsprache vom 22.09.2026
• Proxmox VE Roadmap, Volume Chains als Tech-Preview und der Changelog-Beleg zu ZFS over iSCSI