TrueNAS-Proxmox-Plugin: Wann ist es sinnvoll?

Das neue TrueNAS-Proxmox-Plugin löst ein ganz bestimmtes Problem: Sie nutzen bereits TrueNAS als Speicher für Proxmox und möchten nicht mehr jedes Mal manuell Block-Storage konfigurieren und mappen, wenn sich eine VM-Festplatte ändert.

Es verwandelt TrueNAS nicht in Proxmox, macht lokales ZFS auf Proxmox nicht überflüssig und verleiht einer TrueNAS Community Edition auch kein Enterprise-Storage-HA. Was es tut: Es lässt ein separates TrueNAS-System deutlich stärker wie ein natives Proxmox-Storage-Backend wirken.

Wenn Sie im Proxmox-Webinterface eine Festplatte erstellen, kann das Plugin das passende ZFS-Volume auf TrueNAS anlegen, es über iSCSI oder NVMe/TCP bereitstellen und mit der VM verbinden. Dieselbe Integration deckt Snapshots, Größenänderungen, Klonen, Migrationen und das Löschen ab. Das ist praktisch, auch wenn die Frage bleibt, ob Ihre Architektur diesen Ansatz wirklich braucht.

Was das TrueNAS-Proxmox-Plugin tatsächlich ersetzt

Vor allem den manuellen Aufwand zwischen Proxmox VE und dem Block-Storage auf TrueNAS. Ohne das Plugin erfordert ein typischer iSCSI-Workflow mehrere Schritte: Sie erstellen ein Zvol auf TrueNAS, legen ein Extent an, verknüpfen das Extent mit einem Target, bestätigen das LUN-Mapping, führen in Proxmox einen Rescan durch und weisen das Blockgerät schließlich einer VM zu. Wenn Sie das zweimal im Jahr machen, ist das erträglich. Wenn Proxmox jedoch Ihre zentrale Virtualisierungsplattform ist und ständig virtuelle Festplatten erstellt, vergrößert, geklont, verschoben und gelöscht werden, wird der Prozess schnell lästig. Das Plugin wandelt diese manuellen Speichereingriffe in einfache API-Aufrufe um.

TrueNAS beschreibt das Plugin als Storage-Backend für Proxmox VE in Kombination mit TrueNAS 25.10 oder neuer. Sie installieren es auf den Proxmox-Knoten, nicht auf dem TrueNAS-Server. Proxmox kommuniziert über die TrueNAS-API, um ZFS-basierte Blockgeräte zu erstellen und zu verwalten, während der eigentliche Datenpfad über iSCSI oder NVMe/TCP läuft. Die Steuerungsebene verläuft also über die API, während der tatsächliche VM-Speicherverkehr weiterhin über ein reguläres Block-Storage-Protokoll fließt.

Für Administratoren bedeutet das, dass Operationen für VM-Disks direkt in der Proxmox-Oberfläche bleiben, statt Speicherobjekte von Hand zusammenzubauen. Eine treffende Reaktion auf die Ankündigung fasste den Vorteil prägnant zusammen: Aus dem Ablauf

create zvol -> map extent -> map target -> rescan -> attach

wird im Grunde:

create new disk

Der Mr.PlanB Proxmox-Hub beleuchtet die grundlegenden Entscheidungen rund um Storage und Cluster, die einer solchen Integration zugrunde liegen.

Ist das nützlich, wenn Proxmox bereits ZFS unterstützt?

Nur dann, wenn der ZFS-Speicher auf einem separaten System liegt. Genau darum drehte sich die zentrale Diskussion nach der Ankündigung.

Proxmox VE unterstützt ZFS direkt ab Werk. Wenn Ihre Festplatten physisch im Proxmox-Host verbaut sind und Sie lediglich VM-Disks auf ZFS benötigen, bringt TrueNAS zwischen Proxmox und diesen Laufwerken nur eine zusätzliche Schicht, ohne ein echtes Problem zu lösen. Lokales ZFS auf Proxmox ist in diesem Fall meist die unkompliziertere Wahl.

Das Plugin entfaltet seinen Nutzen erst, wenn TrueNAS als eigenständiges Speichersystem agiert. Stellen Sie sich drei Proxmox-Compute-Nodes vor, die mit einer dedizierten TrueNAS-Appliance verbunden sind. Auf den Compute-Knoten selbst liegt kein VM-Speicher, und alle drei Hosts müssen denselben Block-Storage sehen, damit Workloads nahtlos zwischen ihnen migriert werden können. In diesem Szenario dient TrueNAS als zentralisierter Shared Storage, was eine ganz andere Aufgabe ist als lokales ZFS auf einzelnen Proxmox-Servern.

Proxmox beherrscht ZFS problemlos selbst. Das Plugin vereinfacht jedoch die Anbindung an Speicher, der von einem anderen ZFS-System verwaltet wird, und genau dort hat es seine Berechtigung.

Warum nicht einfach NFS nutzen?

Das können Sie weiterhin tun. NFS gehört zu den unkompliziertesten Wegen, TrueNAS und Proxmox zu verbinden, und reicht für viele kleinere Umgebungen völlig aus. Sie erstellen ein NFS-Dataset, exportieren es, binden es als Proxmox-Storage ein, und schon können mehrere Nodes darauf zugreifen.

Das Plugin richtet sich gezielt an Administratoren, die Block-Storage und natives Snapshot-Verhalten auf Storage-Ebene bevorzugen. TrueNAS argumentiert, dass NFS-basierte VM-Disks Performance-Nachteile bei Snapshots mit sich bringen können, da Proxmox auf Dateisystem-Storage typischerweise auf Copy-on-Write-Formate von QEMU setzt. Bei großen virtuellen Festplatten können solche Vorgänge spürbare Verzögerungen verursachen und Workloads beeinträchtigen. Block-Storage vermeidet diesen Umweg, und das Plugin ermöglicht es TrueNAS, ZFS-Snapshots direkt unterhalb der Proxmox-Ebene zu verwalten. Das entspricht viel eher dem Verhalten, das Administratoren von klassischen Storage-Arrays gewohnt sind.

Das bedeutet nicht, dass iSCSI grundsätzlich besser als NFS ist. NFS ist leichter zu verstehen, einfacher bei der Fehlersuche, benötigt weniger Block-Storage-Unterbau und eignet sich hervorragend für ISOs, Backups, Templates und Standard-VMs. Das Plugin wird dann attraktiv, wenn Snapshot-Performance, Thin Provisioning, Multipathing, die isolierte Verwaltung virtueller Disks oder blockbasierter Hochleistungszugriff für Sie entscheidend sind.

TrueNAS selbst empfiehlt ein gemischtes Design: das Plugin für blockbasierten VM-Storage sowie NFS oder SMB auf demselben System für ISO-Images, Backups oder gewöhnliche Datei-Freigaben.

Warum kein normales iSCSI ohne Plugin?

Reines iSCSI sorgt zwar für die Netzwerkverbindung, automatisiert aber nicht den Lebenszyklus des Speichers. Ein iSCSI-Target stellt Blockgeräte für Proxmox zuverlässig bereit. Die Umständlichkeit beginnt in dem Moment, in dem Sie ein weiteres Blockgerät benötigen, weil dieses manuell angelegt werden muss. In einem kleinen Homelab erledigen Sie das selbst, in einem Unternehmen bedeutet das oft ein Ticket an das Storage-Team.

Das Plugin verlagert diesen Arbeitsaufwand direkt in Proxmox. Sobald eine VM-Disk erstellt wird, kann die TrueNAS-API das zugehörige Zvol sowie das Storage-Mapping automatisch erzeugen. Wird die Disk gelöscht, bereinigt das Plugin die zugrundeliegenden Speicherobjekte wieder. Das Ändern der Festplattengröße und das Erstellen von Snapshots folgen demselben Muster. Das kommt der gewohnten Storage-Integration aus der VMware-Welt deutlich näher.

Das erklärt auch, warum Unternehmen sich stärker dafür interessieren als frühe Reaktionen aus der Homelab-Community vermuten ließen. Wer privat experimentiert, kann zu Recht sagen: "Ich erstelle einmal im Jahr ein Zvol, wozu brauche ich dafür eine Integration?" Ein Virtualisierungsteam, das Hunderte von Disks bereitstellt, bewertet das völlig anders, weil das Einsparen wiederkehrender Speichertickets spürbar Arbeitszeit freisetzt.

Was bringt NVMe/TCP zusätzlich?

Einen Blockzugriff mit geringerem Protokoll-Overhead, was zu den spannendsten Aspekten des Plugins zählt, allerdings an Versionsvoraussetzungen gebunden ist. Laut TrueNAS-Dokumentation unterstützt das Plugin iSCSI sowie NVMe/TCP, wobei der NVMe/TCP-Modus Proxmox VE 9.x oder neuer erfordert.

Damit ist das Plugin mehr als ein reines Automatisierungswerkzeug für iSCSI. In Verbindung mit schnellem NVMe-Speicher und zeitgemäßen Ethernet-Netzwerken bietet NVMe/TCP einen direkteren Übertragungsweg zwischen Virtualisierungshosts und Flash-Speicher als ältere SCSI-basierte Protokolle. Die Ankündigung weckte genau hier großes Interesse: Mehrere Administratoren sahen den Hauptvorteil weniger in der Weboberfläche als vielmehr in einem nativen Drittanbieter-Storage-Backend, das NVMe/TCP für Proxmox bereitstellt.

Die klassischen Überlegungen beim Storage-Design bleiben jedoch auch mit einem modernen Protokoll bestehen. Netzwerkredundanz, Multipathing und Latenzen spielen weiterhin eine zentrale Rolle. Handelt es sich beim TrueNAS-System um ein Gerät mit nur einem Controller, bleibt dieser ein Single Point of Failure. Ein schnelleres Protokoll verwandelt eine Speicher-Appliance ohne Hochverfügbarkeit nicht magisch in ein HA-System.

Macht das Plugin TrueNAS zur Alternative für Ceph?

Es kann eine Alternative sein, basiert jedoch auf einer völlig anderen Architektur. Ein klassischer Proxmox-Ceph-Cluster verteilt den Speicher direkt über die Proxmox-Nodes selbst, sodass Compute und Storage hyperkonvergent zusammenfallen. Fällt ein Storage-Node aus, stellen die verbleibenden Knoten die replizierten Daten weiterhin bereit, vorausgesetzt, der Cluster wurde mit ausreichender Fehlertoleranz geplant.

Ein TrueNAS-basiertes Konzept trennt diese Schichten üblicherweise: Die Proxmox-Knoten übernehmen das Compute, TrueNAS liefert den Speicher. Das kann einfacher im Betrieb sein, insbesondere wenn eine Organisation bereits über ein leistungsfähiges Speichersystem verfügt oder reine Compute-Nodes ohne umfangreiche lokale Festplattenbestände bevorzugt. Ein dediziertes Speichersystem kann zudem sehr hohe Durchsatzwerte erzielen. Ein Administrator schilderte in den Diskussionen, wie er TrueNAS als MPIO-SCSI-Target über redundante 100GbE-Verbindungen einsetzt, weil dies für seine Workloads eine höhere Leistung als Ceph lieferte. Das ist ein konkreter Einzelfall und sollte nicht als allgemeingültiger Benchmark verstanden werden.

Wichtiger ist der architektonische Kompromiss: Bei einem standardmäßigen TrueNAS-Server wird das Speichersystem zur zentralen Abhängigkeit. TrueNAS Enterprise bietet zwar Dual-Controller-HA auf zertifizierter Hardware, aber die Community Edition verwandelt beliebige Standardserver nicht in redundante Storage-Controller. Aus diesem Grund empfiehlt TrueNAS, das Plugin als getrenntes Compute und Storage zu betrachten und nicht als direkten Ersatz für Ceph.

Wenn Ihr Ziel darin besteht, Ceph zu erlernen oder aufzubauen, bietet der Proxmox Health Check eine nützliche Orientierung: Quorum, Speichernetzwerke, Replikationskonzepte und Failure Domains sind weit wichtiger als ein Pool, der lediglich im Webinterface grün angezeigt wird.

Ist dieses Plugin heute schon produktionsreif?

Nein, laut der offiziellen TrueNAS-Dokumentation ist es das derzeit nicht. Beachten Sie diesen Punkt, bevor Sie den Installationsbefehl von GitHub ausführen. TrueNAS kennzeichnet das Proxmox VE Storage Plugin aktuell mit folgenden Hinweisen:

• in aktiver Entwicklung
• noch nicht vollständig getestet
• für die TrueNAS Community Edition vorgesehen
• noch nicht auf TrueNAS-Enterprise-Systemen unterstützt
• nicht für produktive Workloads empfohlen

Die Ankündigung aus dem September hält fest, dass die Validierung für Enterprise-Systeme derzeit läuft. Bei genauem Hinsehen widersprechen sich diese Aussagen nicht: Der Code existiert, Nutzer der Community Edition können ihn testen, die Enterprise-Prüfung schreitet voran, aber ein offizieller Produktiv-Support liegt noch nicht vor.

Das ist relevant, weil genau die Konfiguration, die am meisten von dem Plugin profitiert, geteilter Speicher unter mehreren Virtualisierungsknoten, auch diejenige ist, bei der maximale Stabilität gefordert ist. Ein Fehler im Storage-Plugin kann die VM-Erstellung, Snapshots, Migrationen, das Löschen oder den Zugriff auf das zugrundeliegende Volume stören. Nur weil Code auf GitHub bereitsteht, ist er noch lange nicht reif für Produktivcluster.

TrueNAS rät dazu, das Plugin zunächst in Testumgebungen auszuprobieren, und genau diese Vorgehensweise ist ratsam.

Welche Sicherheitskompromisse gibt es?

Das Plugin erreicht seine Automatisierung dadurch, dass es Proxmox erweiterte Rechte auf dem TrueNAS-System einräumt. Nach aktuellem Stand müssen Proxmox-Knoten die WebSocket-API von TrueNAS über HTTPS auf Port 443 sowie den Speicherdienst über iSCSI auf TCP-Port 3260 erreichen können. NVMe/TCP nutzt einen eigenen Pfad. Zudem speichert die Proxmox-Storage-Konfiguration einen TrueNAS-API-Schlüssel mit ausreichenden Rechten, um Datasets und Block-Storage-Ressourcen zu verwalten. Das erfordert mehr Vertrauen als bei einem Host, der lediglich auf eine vorab manuell erstellte iSCSI-LUN zugreifen darf.

Eine frühe Sorge in den Diskussionen betraf die Frage, ob das Plugin einen SSH-Zugriff von Proxmox auf TrueNAS verlangt. Die Dokumentation beschreibt SSH jedoch nicht als Steuerungsweg, sondern nutzt die TrueNAS-API. Das ist für die Zugriffskontrolle vorteilhaft, macht den API-Schlüssel aber dennoch zu einem sensiblen Element. Wird ein Proxmox-Host kompromittiert, erlangt ein Angreifer potenziell alle Rechte, die mit diesem Schlüssel verknüpft sind.

Behandeln Sie das Speichernetzwerk und die Management-API als geschützte Infrastrukturnetze, getrennt vom normalen LAN-Verkehr der Clients. In der Praxis bedeutet das: Vergeben Sie nur die minimal erforderlichen API-Rechte, schränken Sie ein, welche Proxmox-Knoten die TrueNAS-Management-API ansprechen dürfen, und sichern Sie das Speichernetzwerk separat ab.

Bequeme Automatisierung reduziert Berechtigungen nicht, meist ist das Gegenteil der Fall, da der automatisierte Dienst alle Rechte benötigt, die zuvor manuell ausgeübt wurden.

Was spricht gegen TrueNAS als VM in Proxmox?

Hierbei handelt es sich um eine andere Architektur als diejenige, für die das Plugin konzipiert wurde. Dieses Modell funktioniert zwar und wird in vielen Homelabs praktiziert: Administratoren reichen einen HBA oder physische Festplatten an eine TrueNAS-VM durch, lassen TrueNAS den ZFS-Pool verwalten und stellen den Speicher anschließend anderen VMs oder Systemen bereit.

Die offensichtliche Hürde sind zirkuläre Abhängigkeiten. Wenn Proxmox Speicher von einer TrueNAS-VM benötigt, die ihrerseits Proxmox zum Booten braucht, werden Startreihenfolge und Disaster Recovery schnell kompliziert. Ein Nutzer berichtete, dass er bewusst alle für das Booten von Proxmox oder kritischen VMs benötigten Daten außerhalb der virtualisierten TrueNAS-Instanz hielt und diese ausschließlich für unkritische Massendaten nutzte. Das ist ein pragmatischer Weg, um wechselseitige Abhängigkeiten zu begrenzen.

Dennoch ist das nicht das primäre Einsatzgebiet des Plugins. Seine Stärken liegen bei einem dedizierten TrueNAS-System, das mehrere Proxmox-Knoten versorgt. Dadurch erhält die Speicherschicht ihre eigene Hardware, ihren eigenen Lebenszyklus, getrennte Netzwerkschnittstellen und eine klare Ausfallgrenze.

Wer sollte dieses Plugin testen?

Drei Gruppen profitieren besonders schnell von einem Test. Erstens alle Administratoren, die Proxmox bereits mit TrueNAS über manuell verwaltetes iSCSI betreiben. Das Plugin setzt exakt an den Arbeitsschritten an, die im Alltag monoton und fehleranfällig sind.

Zweitens Projekte zur VMware-Migration, bei denen Unternehmen Proxmox für Compute nutzen wollen, ohne gleichzeitig ihre Speicherarchitektur grundlegend umzubauen. Die Beibehaltung einer separaten Shared-Storage-Infrastruktur kann den Wechsel des Hypervisors erheblich vereinfachen.

Drittens Testumgebungen, die Block-Storage über iSCSI oder NVMe/TCP evaluieren wollen, bevor Entscheidungen über den Aufbau größerer Proxmox-Umgebungen getroffen werden.

Wer benötigt das Plugin eher nicht? Ein einzelner Proxmox-Host mit lokalen Festplatten und lokalem ZFS, kleinere Umgebungen, die mit NFS wunschlos glücklich sind, Cluster mit Fokus auf Ceph oder Setups, in denen TrueNAS lediglich SMB-Freigaben für Mediendateien bereitstellt.

Gerade der klar umrissene Funktionsumfang macht das Plugin nützlich: Es verbindet zwei bewährte Lösungen und beseitigt eine Schicht manueller Speicheradministration.

Wo die Speicherzuständigkeit liegt

Die Diskussion verkürzt sich oft auf den Vergleich "TrueNAS ZFS gegen Proxmox ZFS", was am eigentlichen Zweck des Plugins vorbeigeht. Beide Systeme nutzen OpenZFS und beherrschen die Speicherverwaltung. Der Unterschied liegt darin, wo die Verantwortung für den Speicher organisatorisch und architektonisch verankert ist.

Gehören die Festplatten zu einem einzelnen Proxmox-Host, ist natives ZFS auf Proxmox an Einfachheit kaum zu übertreffen. Benötigen mehrere Proxmox-Hosts gemeinsam genutzten Speicher von einem dedizierten TrueNAS-System, bietet das Plugin klare Vorteile. Und wenn Sie hyperkonvergenten Speicher suchen, der den Ausfall einzelner Compute-Knoten ohne separate Storage-Appliance abfängt, ist Ceph die passendere Lösung.

Das Plugin nimmt Ihnen diese Architekturentscheidungen nicht ab, macht aber eine dieser Varianten im laufenden Betrieb spürbar komfortabler.

Testen Sie das Plugin in Laborumgebungen und verzichten Sie vorerst auf den Produktiveinsatz. Sollte TrueNAS das Plugin von der frühen Entwicklungsphase zu einer offiziell unterstützten Enterprise-Integration weiterführen, könnte es zu einer der praktischsten Speicheroptionen für Unternehmen werden, die ihre Virtualisierung auf Proxmox umstellen, ohne gleichzeitig ihre Storage-Architektur neu erfinden zu müssen.