TrueNAS-Proxmox-Plugin verlaesst die Vorankuendigung: Early-Adopter-Rollout mit signiertem APT-Repo

Im April 2026 haben wir eingeordnet, was das offizielle TrueNAS-Plugin fuer 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 Abhaengigkeiten. Das aendert sich jetzt. iXsystems hat den offiziellen Rollout-Post zum TrueNAS-Proxmox-Plugin veroeffentlicht 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 abhaengig zu sein?” Antwort: jetzt.

Was iXsystems konkret angekuendigt hat

Der Rollout-Post nennt vier neue Aspekte, die ueber die April-Ankuendigung hinausgehen:

1. Signierte APT-Repositories fuer 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 supportfaehigen Storage-Integration.

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

3. Multi-Tenancy fuer mehrere PVE-Cluster gegen eine TrueNAS. Das war im April-Post noch nicht explizit. Eine einzelne TrueNAS-Appliance kann jetzt als Storage-Backend fuer mehrere getrennte Proxmox-Cluster dienen, ohne dass sich diese in die Quere kommen. Fuer Systemhaeuser mit mehreren Mandanten oder fuer groessere Hausumgebungen mit mehreren Cluster-Faellen ist das ein echter Meilenstein.

4. Offizieller Reifegrad: Early Adopter. Das ist keine „Vorankuendigung” mehr, aber auch noch nicht GA. Enterprise-Validierung laeuft, Produktions-Support ist noch nicht ueberall zugesichert. Das Gate liegt jetzt beim Betreiber, nicht beim Hersteller.

Voraussetzungen im Ueberblick

Komponente	Anforderung
TrueNAS	25.10 oder spaeter (Goldeye)
Proxmox VE	8.x oder spaeter — 9.x wird explizit empfohlen
Netzwerk	10 GbE Minimum fuer iSCSI, 25 GbE aufwaerts fuer NVMe/TCP realistisch
Zusatzpaket fuer 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 heissen

Der Rollout-Post nennt drei Installationsvarianten. Fuer die Praxis heisst das:

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

Fuer den Grossteil unserer Kunden ist der APT-Weg der richtige. Der interaktive Installer eignet sich fuer den ersten Aufbau, danach uebernimmt der Regelbetrieb per APT.

Was „Early Adopter” fuer Ihr Projekt bedeutet

Der Begriff ist bewusst zwischen „Beta” und „GA” gewaehlt. Praktisch bedeutet er:

• Ja fuer Test- und Vorproduktionsumgebungen. Das Plugin ist installierbar, dokumentiert und wird von iXsystems aktiv gepflegt. Fuer eine reine Test-Umgebung ist der Reifegrad ausreichend.
• Bedingt ja fuer 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 supportfaehigen Distributionsweg.
• Noch nicht fuer geschaeftskritische HA-Cluster mit strikter Enterprise-Support-Pflicht. Solange die Enterprise-Validierung laeuft, gehoert 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 pruefen, 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 Aenderung. Fuer Systemhaeuser mit gemischtem Kundenbestand oder fuer Konzern-IT-Abteilungen mit mehreren Standorten heisst das:

• Eine TrueNAS-Enterprise-Appliance kann als Backend fuer 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 fuer drei Cluster reicht ggf. eine groessere Appliance. Details klaeren 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.

Fuer Kunden mit mehreren produktiven Proxmox-Clustern ist genau das haeufig 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.
• Groessere hyperkonvergente Ceph-Cluster haben ihre eigene Storage-Ebene und muessen die Frage stellen, ob sie zwei Storage-Konzepte parallel fahren wollen. Meist besser: Ceph fuer Compute, TrueNAS fuer File-Server und Backup-Target.
• HA-Cluster mit strengen SLAs, die auf Enterprise-Support angewiesen sind, warten sinnvollerweise auf die GA-Freigabe und die naechste iXsystems-Support-Matrix.

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

Was das fuer laufende Storage-Projekte heisst

Wenn Sie gerade ein Proxmox- oder TrueNAS-Projekt planen, veraendert 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 unnoetig, wenn 9.x heute stabil ist.
2. TrueNAS 25.10 (Goldeye) ist Voraussetzung. Aeltere TrueNAS-Versionen unterstuetzen die notwendigen APIs nicht. Wer aufruestet, plant den Upgrade-Pfad frueh — DATAZONE Storage-Beratung hilft bei der Migration.
3. Storage-Netz mit Reserven planen. NVMe/TCP zeigt seine Staerken erst ab 25 GbE aufwaerts. Wer heute 10 GbE plant, sollte mindestens 25-GbE-Uplinks am TrueNAS-Head vorsehen — die zusaetzlichen Ports kosten wenig gegenueber einer Nachruestung.

Fuer 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 verfuegbar?

Ab sofort in der Early-Adopter-Phase. Signierte APT-Pakete fuer Debian Bookworm und Trixie sowie ein standalone .deb-Paket sind ueber die offizielle iXsystems-Distribution verfuegbar. Ein GA-Termin ist noch nicht veroeffentlicht.

Welche Voraussetzungen gelten?

TrueNAS 25.10 oder spaeter, Proxmox VE 8.x oder spaeter (9.x wird empfohlen). Fuer NVMe/TCP zusaetzlich nvme-cli auf jedem PVE-Node. Ein sinnvoll dimensioniertes Storage-Netz gehoert dazu — mindestens 10 GbE fuer iSCSI, 25 GbE aufwaerts fuer NVMe/TCP.

Was heisst „Early Adopter” konkret?

Das Plugin ist installierbar, dokumentiert und wird herstellergepflegt, aber die Enterprise-Support-Validierung laeuft noch. Fuer Test- und Vorproduktionsumgebungen freigegeben, fuer geschaeftskritische HA-Cluster empfehlen wir die GA-Freigabe abzuwarten. Der Unterschied zu einer klassischen Beta: das Plugin ist bereits Produktions-tauglich fuer geeignete Workloads, es fehlt „nur” die formale Enterprise-Zusicherung.

Kann eine TrueNAS mehrere Proxmox-Cluster versorgen?

Ja, ueber die neu vorgestellte Multi-Tenancy. Datasets, iSCSI-LUNs und Snapshots werden pro Cluster isoliert. Fuer Systemhaeuser und Konzern-IT mit mehreren Standorten ist das der praktisch relevanteste Sprung im Rollout.

Muessen wir von BoomshankerX oder freenas-proxmox migrieren?

Nicht zwingend — BoomshankerX laeuft weiter. Perspektivisch fokussiert sich die Pflege aber auf das offizielle Plugin. Fuer Neuprojekte gibt es keinen Grund mehr, ein Community-Plugin zu waehlen. Fuer bestehende Deployments empfehlen wir eine geplante Migration im naechsten Wartungsfenster, nicht sofort.

Wie unterscheidet sich der Installer vom apt install-Weg?

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

Was empfiehlt DATAZONE fuer Neuprojekte?

Proxmox VE 9.x + TrueNAS 25.10 (Goldeye) + Storage-Netz mit 25-GbE-Reserve + Test-Deployment ueber APT-Repo mit vierwoechigem Probelauf. Wer eine TrueNAS-Konfiguration plant oder Unterstuetzung bei der Proxmox-Umsetzung braucht, meldet sich am besten frueh — der Plugin-Rollout hat Auswirkungen auf Netz- und Storage-Design, die spaeter teuer werden.