Im Oktober 2025 haben wir das BoomshankerX-Plugin getestet — die damals beste Community-Lösung, um TrueNAS sauber an Proxmox VE anzubinden. Jetzt ist viel passiert: iXsystems pflegt seit Anfang 2026 ein eigenes, offizielles Plugin unter github.com/truenas/truenas-proxmox-plugin. Es bringt Funktionen, die das Community-Plugin nicht hatte — am wichtigsten: NVMe/TCP als Transport. Und nach Aussage der Entwickler steht zudem die native Integration ins Proxmox-WebUI unmittelbar bevor.

Hier eine ehrliche Standortbestimmung — was sich geändert hat, was das neue Plugin kann, was es noch nicht kann, und wann ein Wechsel sich lohnt.

Was ist neu?

Bisher gab es drei nennenswerte Plugin-Varianten:

freenas-proxmox (TheGrandWazoo) — ältere SSH-/REST-basierte Integration für FreeNAS
boomshankerx/proxmox-truenas — moderne WebSocket-API-Integration, schlank gehalten
WarlockSyno/TrueNAS-Proxmox-VE-Storage-Plugin — feature-reicher Community-Fork mit Multipath-Schwerpunkt

Seit Februar 2026 ist github.com/truenas/truenas-proxmox-plugin die offizielle, von iXsystems selbst entwickelte und gepflegte Lösung. Die TrueNAS-Dokumentation bezeichnet das Plugin wörtlich als “developed and maintained by TrueNAS”. Damit gibt es zum ersten Mal eine herstellergetragene Integration — vorher war das Feld komplett Community.

Features im Überblick

Das README listet 14 Kernfunktionen:

Feature	Bedeutung
Dual Transport	iSCSI oder NVMe/TCP — pro Storage-Eintrag wählbar
iSCSI Block Storage	Klassische LUN-Bereitstellung über zvols
NVMe/TCP Support	Neuer Transport, ab TrueNAS SCALE 25.10
ZFS Snapshots	Instant, platzsparend über die TrueNAS-API
Live Snapshots (vmstate)	VM-Snapshots inklusive RAM-Zustand
Cluster Compatible	Volle Unterstützung für Proxmox-Cluster
Automatic Volume Management	zvol-Erstellung, Extent-/Target-Mapping vollautomatisch
Configuration Validation	Pre-flight-Checks vor jedem Storage-Vorgang
Rate Limiting Protection	API-Throttling-Schutz gegen Überlastung
Storage Efficiency	Thin Provisioning + ZFS-Komprimierung (LZ4 etc.)
Multi-path Support	Native iSCSI-Multipath-Konfiguration
CHAP Authentication	Optional für iSCSI-Sicherheit
Volume Resize	Mit Pre-flight Space-Check
Error Recovery	Robustes Verhalten bei API-Hängern und Verbindungsabbrüchen

Quelle: README im offiziellen Repo, Stand v2.0.6 (12. März 2026).

NVMe/TCP: der wichtigste Sprung

Der größte technische Unterschied zur Vorgänger-Welt ist NVMe/TCP als Alternative zu iSCSI. iSCSI ist etabliert und funktioniert, hat aber zwei strukturelle Schwächen: SCSI-Protokoll-Overhead in jedem Frame und ein Single-Queue-Modell pro Session. NVMe/TCP ersetzt das durch das NVMe-Befehlsset über TCP — mit Multi-Queue-Architektur und deutlich weniger CPU-Last pro IOPS.

Verifizierte Benchmark-Werte (Blockbridge, Proxmox: iSCSI and NVMe/TCP shared storage comparison — anerkannte Quelle in der Proxmox-Community):

Workload	NVMe/TCP vs. iSCSI
Kleine I/O (allgemein)	+30 % IOPS, −20 % Latenz
4K Random Read	+51 % Peak-IOPS, −34 % Latenz
QD1 (single-thread)	+18 % Performance
Großes sequentielles I/O	praktisch identisch (~0,1 % Differenz)

Wichtige Einordnung: Die Vorteile schlagen vor allem bei kleinen I/O-Größen und niedrigen Queue-Depths durch — also genau dort, wo VMs typischerweise leben (Datenbank-Commits, Metadaten-Operationen, OS-Boot-Storms). Bei reinen Streaming-Workloads (Video-Render, Backup-Restore) gleichen sich beide Protokolle an, weil das Bottleneck dann das Netzwerk selbst ist.

Eigene Messungen ohne kontrolliertes Setup haben wir bewusst nicht gemacht — die Zahlen oben sind Blockbridge-Werte aus einem reproduzierbaren Test-Aufbau, nicht aus unseren eigenen Boxen.

iSCSI oder NVMe/TCP — wann was?

Szenario	Empfehlung
Virtualisierung mit vielen kleinen VMs	NVMe/TCP — Latenz-Gewinn pro VM-Boot/-Login spürbar
Datenbank-VMs (PostgreSQL, MSSQL, MySQL)	NVMe/TCP — Sync-Write-Latenz besonders wichtig
Backup-Targets, Media-Storage	iSCSI bleibt valide — Bandbreitenlimit liegt am Netzwerk
Bestehende iSCSI-Multipath-Infrastruktur	iSCSI weiter nutzen — Plugin verwaltet beides parallel
Gemischte Cluster (alte + neue PVE-Nodes)	iSCSI — NVMe/TCP setzt PVE 9.x voraus

NVMe/TCP setzt voraus: TrueNAS SCALE 25.10+, Proxmox VE 9.x, sowie das nvme-cli-Paket auf den PVE-Nodes. Wer noch auf PVE 8.x ist, bekommt ausschließlich iSCSI.

Vorteile gegenüber klassischer Anbindung

Die “klassische” Anbindung — manuell iSCSI auf TrueNAS einrichten, Targets/Extents von Hand pflegen, dann in Proxmox einen iSCSI-Storage-Pool ergänzen und LVM darüber legen — funktioniert seit Jahren. Das offizielle Plugin nimmt diesem Setup an mehreren Stellen Arbeit ab:

1. ZVol-Lifecycle vollautomatisch Beim Anlegen einer VM-Disk in Proxmox erzeugt das Plugin auf TrueNAS automatisch ein zvol passender Größe, registriert es als iSCSI-Extent, mappt es ins Target und meldet die LUN zurück. Beim Löschen geht es den umgekehrten Weg. Manuell wäre das pro VM-Disk ein 4-Schritte-Prozess in der TrueNAS-WebUI.

2. Echte ZFS-Snapshots, nicht qcow2-Snapshots Proxmox-Snapshots auf klassischem iSCSI-LVM sind LVM-Snapshots — funktional begrenzt und mit Performance-Einbußen. Das Plugin nutzt native ZFS-Snapshots über die TrueNAS-API. Das heißt: instant, platzsparend (Copy-on-Write) und mit Live-vmstate optional inklusive RAM.

3. Multi-Node-Cluster ohne Drift In einem PVE-Cluster ohne Plugin muss jeder Node die iSCSI-Konfiguration selbst kennen. Das Plugin verwaltet die Storage-Definition zentral in /etc/pve/storage.cfg — bei einem Cluster-Sync sind alle Nodes konsistent.

4. CHAP, Multipath, Rate-Limiting out of the box Statt manueller Pflege von /etc/iscsi/iscsid.conf und Multipath-Targets pflegt das Plugin diese Aspekte über Storage-Parameter. CHAP-User landen in der storage.cfg, Multipath-Pfade werden als Discovery-Portale gepflegt.

5. Pre-flight Validation und Error Recovery Vor jedem destruktiven Vorgang (Volume-Resize, Snapshot-Rollback) prüft das Plugin Plausibilität und freien Platz. API-Hänger oder Verbindungsabbrüche werden mit Retry-Logik abgefangen — statt halb-fertige Konfigurationen zu hinterlassen.

Native Proxmox-WebUI-Integration: was bekannt ist

Aktueller Stand laut README: Das Plugin wird über /etc/pve/storage.cfg oder den interaktiven Installer konfiguriert. Es gibt noch kein natives Add-Storage-Formular im Proxmox-WebUI — der Storage-Type “TrueNAS” muss manuell oder per Skript angelegt werden.

Aus den Diskussionen im Proxmox-Forum-Thread zum Plugin und nach Aussagen aus dem TrueNAS-Umfeld ist eine native WebUI-Integration in Proxmox VE 9.1 in Vorbereitung. Konkret heißt das: TrueNAS würde als eigenständiger Storage-Typ neben “iSCSI”, “NFS”, “CIFS” etc. im PVE-Auswahlmenü erscheinen, mit eigenem Konfigurationsdialog.

Wichtige Einordnung: Wir haben diese Information aus dem Umfeld der Entwickler — eine offiziell datierte Ankündigung von Proxmox Server Solutions GmbH liegt zum Stand 29. April 2026 nicht vor. Wer Planungssicherheit für eine Migration braucht, sollte die Veröffentlichung der PVE-9.1-Release-Notes abwarten.

Versionsanforderungen

Aus dem README (Stand v2.0.6):

Proxmox VE 8.x oder neuer (9.x empfohlen)
TrueNAS SCALE 25.10 oder neuer (zwingend — keine Rückwärtskompatibilität zu 24.x)
iSCSI-Port 3260 vom PVE-Node zum TrueNAS erreichbar
WebSocket-API auf Port 443 (TLS) zum TrueNAS erreichbar
Für NVMe/TCP zusätzlich: PVE 9.x, nvme-cli auf jedem Node, NVMe-Service auf TrueNAS aktiviert

Aktueller offizieller Lebenszyklus-Status (Zitat aus der TrueNAS-Doku): “in active development and has not been fully tested. Do not use in production workloads.” Das Plugin ist dort heute auf TrueNAS Community Edition ausgerichtet — Enterprise-Support ist angekündigt, aber zum Stand 29. April 2026 noch nicht freigegeben.

Installation in der Praxis

Die einfachste Methode ist das offizielle APT-Repository. Auf jedem Proxmox-Node:

# GPG-Schlüssel hinterlegen
mkdir -p /etc/apt/keyrings
curl -fsSL https://truenas.github.io/truenas-proxmox-plugin/apt/pubkey.gpg \
  -o /etc/apt/keyrings/truenas-proxmox-plugin.gpg

# deb822-Source schreiben
cat >/etc/apt/sources.list.d/truenas-proxmox-plugin.sources <<'EOF'
Types: deb
URIs: https://truenas.github.io/truenas-proxmox-plugin/apt/
Suites: bookworm
Components: main
Architectures: amd64
Signed-By: /etc/apt/keyrings/truenas-proxmox-plugin.gpg
EOF

# Installieren
apt update && apt install -y truenas-proxmox-plugin

Auf PVE 9.x (Trixie-basiert) statt Suites: bookworm einfach Suites: trixie verwenden.

Die TrueNAS-Seite braucht vor der ersten Storage-Anbindung:

Dataset für Proxmox-Volumes anlegen, z.B. tank/proxmox, mit Komprimierung und atime=off
iSCSI-Service aktivieren unter System Settings → Services
iSCSI-Target erzeugen unter Shares → Block Shares (iSCSI) → Targets (Modus iSCSI, Auth optional CHAP)
API-Key generieren unter Credentials → Local Users → root → API Key (oder besser: dedizierter proxmox-api-User)

Anschließend in Proxmox einen Storage-Eintrag in /etc/pve/storage.cfg:

truenasplugin: truenas-storage
    api_host 192.168.1.100
    api_key 1-your-truenas-api-key-here
    target_iqn iqn.2005-10.org.freenas.ctl:proxmox
    dataset tank/proxmox
    discovery_portal 192.168.1.100:3260
    content images
    shared 1

Alle Pfade aus dem offiziellen Wiki.

Migration vom BoomshankerX-Plugin

Wer bereits BoomshankerX einsetzt: Das offizielle Plugin nutzt einen anderen Storage-Typ (truenasplugin statt truenas), die Konfigurationsdateien sind nicht binärkompatibel. Für eine Migration empfehlen wir:

Bestehende Storage-Definition dokumentieren (pvesm status, cat /etc/pve/storage.cfg)
VMs mit Migration-Snapshot sichern — der Wechsel des Storage-Treibers ist kein In-Place-Vorgang
BoomshankerX-Plugin entfernen (apt purge proxmox-truenas-native bzw. proxmox-truenas)
Offizielles Plugin installieren (siehe oben)
Neuen Storage-Eintrag mit Typ truenasplugin anlegen, alten Eintrag entfernen
Disks per qm move-disk von alt nach neu schieben — Snapshots gehen verloren, also vorher dokumentieren
Smoke-Tests mit einer Test-VM, dann produktive VMs nachziehen

In einer typischen Mittelstands-Umgebung (5–20 VMs) ist das ein 2–4-Stunden-Wartungsfenster. Wer NVMe/TCP nutzen will, muss sowieso PVE 9.x voraussetzen — das ist meist der natürliche Zeitpunkt für den Plugin-Wechsel.

Was noch fehlt

Ehrliche Liste der Lücken zum Stand 29. April 2026:

Kein offizielles Production-Ready-Statement — laut Doku weiterhin “in active development, not fully tested”
Kein Enterprise-Support — TrueNAS Community Edition only, Enterprise auf der Roadmap
Keine native PVE-WebUI-Konfiguration — kommt voraussichtlich mit PVE 9.1, ohne offizielles Datum
TPM-Disk-Storage auf iSCSI/NVMe/TCP ist weiterhin eingeschränkt: Der allgemeine TPM-Snapshot-Bug (#4693) wurde in PVE 9.1 behoben — allerdings nur für qcow2-TPM-Disks auf SMB/NFS. Für iSCSI-Direct-Targets ist der Bug noch offen (Bug #3662). Workaround: zusätzliches NFS-Share auf TrueNAS für TPM-Daten
Kein direkter Migrationspfad vom BoomshankerX-Plugin — manuelles Move erforderlich

DATAZONE-Empfehlung

Wann jetzt schon umsteigen:

Sie planen ein Greenfield-Setup mit Proxmox VE 9.x und TrueNAS SCALE 25.10+
Sie wollen NVMe/TCP einsetzen — das gibt es nur im offiziellen Plugin
Sie betreiben Test-/Staging-Umgebungen, in denen “active development” akzeptabel ist
Sie haben Cluster mit hohem Snapshot-Aufkommen — die ZFS-Snapshot-Integration ist deutlich besser als LVM-Snapshots auf klassischem iSCSI

Wann noch warten:

Produktive Umgebungen mit Enterprise-Support-Anforderung — bis das Plugin offiziell als production-ready markiert ist
Bestehende BoomshankerX-Installationen, die stabil laufen und NVMe/TCP nicht brauchen — kein Druck, jetzt zu migrieren
Sie wollen die native WebUI-Integration abwarten — ohne offizielles Datum lieber 1–2 Releases beobachten

Wir testen das Plugin seit den 2.0.x-Versionen in eigenen Lab-Setups und beraten unsere TrueNAS-Kunden zu Migrationszeitpunkten. Bei produktiven Umstellungen schlagen wir typischerweise vor, TrueNAS 25.10 + PVE 9.x + Plugin in einem dedizierten Wartungsfenster zu kombinieren — und nicht in drei einzelnen Schritten verteilt über Wochen.

Quellen

TrueNAS Proxmox Plugin auf GitHub
README, Stand v2.0.6
Installation Wiki
TrueNAS Documentation Hub — Proxmox VE Storage Plugin
Proxmox-Forum-Thread zum Plugin
Blockbridge: Proxmox iSCSI vs NVMe/TCP Comparison (Quelle der NVMe/TCP-Performance-Werte)
Unser Test des BoomshankerX-Plugins, Oktober 2025

Offizielles TrueNAS-Plugin für Proxmox VE: NVMe/TCP, native Integration und der Generationswechsel