TrueNAS-Proxmox-Plugin verlässt die Vorankündigung: Early-Adopter-Rollout mit signiertem APT-Repo

Im April 2026 haben wir eingeordnet, was das offizielle TrueNAS-Plugin für Proxmox VE bringt: NVMe/TCP als Transport, Multipath, CHAP, Cluster-Support, herstellergepflegt statt Community-Fork. Damals war der praktische Weg zum Einsatz aber noch offen: Man klonte das Repo, baute selbst, hoffte auf die passenden Abhängigkeiten. Das ändert sich jetzt. iXsystems hat den offiziellen Rollout-Post zum TrueNAS-Proxmox-Plugin veröffentlicht und dabei drei Dinge konkret gemacht: signierte APT-Pakete, einen cluster-bewussten Installer und den Reifegrad “Early Adopter”.

Diese Nachricht ist praktischer als sie klingt. Sie beantwortet die Frage, mit der wir seit April immer wieder konfrontiert waren: “Wann kann ich das produktiv testen, ohne vom GitHub-Build abhängig zu sein?” Antwort: jetzt.

Was iXsystems konkret angekündigt hat

Der Rollout-Post nennt vier neue Aspekte, die über die April-Ankündigung hinausgehen:

1. Signierte APT-Repositories für Debian Bookworm und Trixie. Damit landet das Plugin auf demselben Distributionsweg wie Proxmox selbst — apt install statt git clone. Das ist der Unterschied zwischen einer Community-Baustelle und einer supportfähigen Storage-Integration.

2. Cluster-bewusster interaktiver Installer mit Health-Checks. Der Installer erkennt, ob er auf einem Standalone-Node oder in einem PVE-Cluster läuft, und passt Konfiguration entsprechend an. Health-Checks prüfen die Voraussetzungen (Kernel-Module, nvme-cli, Netzwerkerreichbarkeit) bevor das Plugin aktiv wird. Wer schon mal einen Cluster mit halb konfiguriertem Storage-Plugin gesehen hat, weiß warum das wichtig ist.

3. Multi-Tenancy für mehrere PVE-Cluster gegen eine TrueNAS. Das war im April-Post noch nicht explizit. Eine einzelne TrueNAS-Appliance kann jetzt als Storage-Backend für mehrere getrennte Proxmox-Cluster dienen, ohne dass sich diese in die Quere kommen. Für Systemhäuser mit mehreren Mandanten oder für größere Hausumgebungen mit mehreren Cluster-Fällen ist das ein echter Meilenstein.

4. Offizieller Reifegrad: Early Adopter. Das ist keine „Vorankündigung” mehr, aber auch noch nicht GA. Enterprise-Validierung läuft, Produktions-Support ist noch nicht überall zugesichert. Das Gate liegt jetzt beim Betreiber, nicht beim Hersteller.

Voraussetzungen im Überblick

Komponente	Anforderung
TrueNAS	25.10 oder später (Goldeye)
Proxmox VE	8.x oder später — 9.x wird explizit empfohlen
Netzwerk	10 GbE Minimum für iSCSI, 25 GbE aufwärts für NVMe/TCP realistisch
Zusatzpaket für NVMe/TCP	nvme-cli auf jedem PVE-Node
APT-Distribution	Bookworm (PVE 8.x) oder Trixie (PVE 9.x)
Storage-Netz	Getrenntes VLAN, MTU 9000 empfohlen

Wer aktuell noch auf TrueNAS 25.04 oder Proxmox VE 7.x sitzt, muss vor dem Plugin ohnehin das Update ziehen. Ein sauberer Upgrade-Pfad ist Voraussetzung, nicht Nice-to-have.

Was die drei Installationswege im Alltag heißen

Der Rollout-Post nennt drei Installationsvarianten. Für die Praxis heißt das:

• Signiertes APT-Paket — der Standardweg für alle Produktionsumgebungen. apt update && apt install mit korrektem Repository-Eintrag, Updates laufen über den gewohnten PVE-Patch-Prozess.
• Interaktiver Installer — für Neuaufbauten und Test-Cluster. Health-Checks, Vorbedingungsprüfung, aktive Steuerung — nützlich für die erste Inbetriebnahme, weniger für wiederholte Deployments.
• Standalone .deb — für Airgap- oder Speziallabor-Umgebungen ohne APT-Zugriff. Auch für Ansible-basierte Rollouts sinnvoll, wo APT-Repos manuell gepflegt werden.

Für den Großteil unserer Kunden ist der APT-Weg der richtige. Der interaktive Installer eignet sich für den ersten Aufbau, danach übernimmt der Regelbetrieb per APT.

Was „Early Adopter” für Ihr Projekt bedeutet

Der Begriff ist bewusst zwischen „Beta” und „GA” gewählt. Praktisch bedeutet er:

• Ja für Test- und Vorproduktionsumgebungen. Das Plugin ist installierbar, dokumentiert und wird von iXsystems aktiv gepflegt. Für eine reine Test-Umgebung ist der Reifegrad ausreichend.
• Bedingt ja für nicht-kritische Produktions-Workloads. Wer bereits das Community-Plugin oder BoomshankerX produktiv fuhr, hat weniger zu verlieren. Der Wechsel bringt NVMe/TCP, Multi-Tenancy und einen supportfähigen Distributionsweg.
• Noch nicht für geschäftskritische HA-Cluster mit strikter Enterprise-Support-Pflicht. Solange die Enterprise-Validierung läuft, gehört ein Storage-Plugin auf HA-Systemen erst nach einer expliziten Freigabe durch iXsystems in Produktion.

Wir empfehlen den folgenden Pfad: Test-Cluster mit APT-Paket aufsetzen, drei bis vier Wochen laufen lassen, Snapshot-, Live-Snapshot- und Failover-Verhalten in Ruhe prüfen, dann bewerten. Wer sich unsicher ist, wo die eigene Umgebung auf dieser Skala liegt, sollte das mit uns durchgehen — bevor der erste PVE-Node umgezogen wird.

Warum Multi-Tenancy der stille Star ist

Von den vier Neuerungen bekommt Multi-Tenancy in der Community bisher am wenigsten Aufmerksamkeit — dabei ist sie technisch die interessanteste Änderung. Für Systemhäuser mit gemischtem Kundenbestand oder für Konzern-IT-Abteilungen mit mehreren Standorten heißt das:

• Eine TrueNAS-Enterprise-Appliance kann als Backend für mehrere PVE-Cluster dienen — trotzdem sind ZFS-Datasets, iSCSI-LUNs und Snapshots pro Cluster isoliert.
• Weniger Storage-Silos, geringere TCO. Statt drei kleiner TrueNAS-Systeme für drei Cluster reicht ggf. eine größere Appliance. Details klären wir zusammen mit dem TrueNAS-Konfigurator.
• Klarer Trennungs-Boundary. Cluster-Admins sehen nur ihren eigenen Bereich; die zentrale Storage-Administration bleibt beim Provider oder der Zentral-IT.

Für Kunden mit mehreren produktiven Proxmox-Clustern ist genau das häufig der Grund, warum sie auf externes Storage-Backend wechseln — und warum das April-Plugin noch nicht die richtige Antwort war.

Wo das Plugin heute noch nicht die richtige Wahl ist

Ehrlich bleiben: nicht jede Umgebung profitiert unmittelbar.

• Kleine Single-Host-PVE-Setups brauchen kein externes Storage-Plugin. Lokales ZFS mit zfs-auto-snapshot und PBS reicht.
• Größere hyperkonvergente Ceph-Cluster haben ihre eigene Storage-Ebene und müssen die Frage stellen, ob sie zwei Storage-Konzepte parallel fahren wollen. Meist besser: Ceph für Compute, TrueNAS für File-Server und Backup-Target.
• HA-Cluster mit strengen SLAs, die auf Enterprise-Support angewiesen sind, warten sinnvollerweise auf die GA-Freigabe und die nächste iXsystems-Support-Matrix.

Das offizielle Plugin ist ein Werkzeug — kein Standard für jede Situation. Wir empfehlen es dort, wo Storage-Konsolidierung oder Multi-Tenancy die konkreten Treiber sind.

Was das für laufende Storage-Projekte heißt

Wenn Sie gerade ein Proxmox- oder TrueNAS-Projekt planen, verändert der Rollout drei praktische Punkte:

1. PVE 9.x wird faktisch zur Empfehlung. Wer neu baut, sollte nicht mehr auf PVE 8 setzen — Migration in 12 Monaten ist unnötig, wenn 9.x heute stabil ist.
2. TrueNAS 25.10 (Goldeye) ist Voraussetzung. Ältere TrueNAS-Versionen unterstützen die notwendigen APIs nicht. Wer aufrüstet, plant den Upgrade-Pfad früh — DATAZONE Storage-Beratung hilft bei der Migration.
3. Storage-Netz mit Reserven planen. NVMe/TCP zeigt seine Stärken erst ab 25 GbE aufwärts. Wer heute 10 GbE plant, sollte mindestens 25-GbE-Uplinks am TrueNAS-Head vorsehen — die zusätzlichen Ports kosten wenig gegenüber einer Nachrüstung.

Für Projekte, die aktuell noch mit BoomshankerX oder dem alten freenas-proxmox laufen, ist der Umstiegszeitpunkt gekommen — aber ohne Zeitdruck. BoomshankerX bleibt funktional, iXsystems empfiehlt aber die Migration auf das offizielle Plugin.

FAQ

Ab wann ist das offizielle TrueNAS-Proxmox-Plugin verfügbar?

Ab sofort in der Early-Adopter-Phase. Signierte APT-Pakete für Debian Bookworm und Trixie sowie ein standalone .deb-Paket sind über die offizielle iXsystems-Distribution verfügbar. Ein GA-Termin ist noch nicht veröffentlicht.

Welche Voraussetzungen gelten?

TrueNAS 25.10 oder später, Proxmox VE 8.x oder später (9.x wird empfohlen). Für NVMe/TCP zusätzlich nvme-cli auf jedem PVE-Node. Ein sinnvoll dimensioniertes Storage-Netz gehört dazu — mindestens 10 GbE für iSCSI, 25 GbE aufwärts für NVMe/TCP.

Was heißt „Early Adopter” konkret?

Das Plugin ist installierbar, dokumentiert und wird herstellergepflegt, aber die Enterprise-Support-Validierung läuft noch. Für Test- und Vorproduktionsumgebungen freigegeben, für geschäftskritische HA-Cluster empfehlen wir die GA-Freigabe abzuwarten. Der Unterschied zu einer klassischen Beta: das Plugin ist bereits Produktions-tauglich für geeignete Workloads, es fehlt „nur” die formale Enterprise-Zusicherung.

Kann eine TrueNAS mehrere Proxmox-Cluster versorgen?

Ja, über die neu vorgestellte Multi-Tenancy. Datasets, iSCSI-LUNs und Snapshots werden pro Cluster isoliert. Für Systemhäuser und Konzern-IT mit mehreren Standorten ist das der praktisch relevanteste Sprung im Rollout.

Müssen wir von BoomshankerX oder freenas-proxmox migrieren?

Nicht zwingend — BoomshankerX läuft weiter. Perspektivisch fokussiert sich die Pflege aber auf das offizielle Plugin. Für Neuprojekte gibt es keinen Grund mehr, ein Community-Plugin zu wählen. Für bestehende Deployments empfehlen wir eine geplante Migration im nächsten Wartungsfenster, nicht sofort.

Wie unterscheidet sich der Installer vom apt install-Weg?

Der interaktive Installer prüft Voraussetzungen (Kernel-Module, nvme-cli, Netzwerkerreichbarkeit) und passt sich an Standalone-Nodes oder Cluster an. Er ist ideal für die erste Inbetriebnahme. Der APT-Weg ist der Standard für Regelbetrieb und Updates — er integriert sich in den gewohnten PVE-Patch-Prozess.

Was empfiehlt DATAZONE für Neuprojekte?

Proxmox VE 9.x + TrueNAS 25.10 (Goldeye) + Storage-Netz mit 25-GbE-Reserve + Test-Deployment über APT-Repo mit vierwöchigem Probelauf. Wer eine TrueNAS-Konfiguration plant oder Unterstützung bei der Proxmox-Umsetzung braucht, meldet sich am besten früh — der Plugin-Rollout hat Auswirkungen auf Netz- und Storage-Design, die später teuer werden.