TrueNAS Proxmox Plugin: When Does It Make Sense?

The new TrueNAS Proxmox plugin solves one specific problem. You already have TrueNAS providing storage to Proxmox, and you're tired of manually creating and mapping block storage every time a VM disk changes.

It won't turn TrueNAS into Proxmox, make local Proxmox ZFS obsolete, or give a Community Edition TrueNAS box enterprise storage HA. What it does is make a separate TrueNAS system behave much more like a native Proxmox storage backend.

Create a disk in the Proxmox interface and the plugin can create the matching ZFS volume on TrueNAS, expose it over iSCSI or NVMe/TCP, and connect it to the VM. The same integration covers snapshots, resizing, cloning, migration, and deletion. That's genuinely useful, although whether your architecture needs it is a separate question.

What does the TrueNAS Proxmox plugin actually replace?

Most of the manual work between Proxmox VE and TrueNAS block storage. Without the plugin, a typical iSCSI workflow means creating a zvol on TrueNAS, creating an extent, associating the extent with a target, confirming the LUN mapping, rescanning storage from Proxmox, and then assigning the resulting block device to a VM. Twice a year, that's manageable. It gets old fast when Proxmox is your main virtualization platform and VM disks are constantly being created, resized, cloned, moved, and destroyed. The plugin turns those storage operations into API calls.

TrueNAS describes it as a Proxmox VE storage backend for TrueNAS 25.10 or newer. You install it on the Proxmox nodes, not on the TrueNAS server. Proxmox talks to the TrueNAS API to create and manage ZFS-backed block devices, and the data path uses either iSCSI or NVMe/TCP. So the control plane runs through the API, while the actual VM storage traffic still goes over a block-storage protocol.

For an administrator, VM disk operations can stay inside the Proxmox UI instead of sending you off to build storage objects by hand. One of the clearest reactions to the announcement described the benefit as turning:

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

into essentially:

create new disk

The Mr.PlanB Proxmox hub covers the broader storage and cluster choices that sit underneath this kind of integration.

Is this useful if Proxmox already supports ZFS?

Only if the ZFS storage lives somewhere else. This was the main argument around the announcement.

Proxmox VE supports ZFS directly. If your disks are physically inside the Proxmox host and all you need is VM disks on ZFS, putting TrueNAS between Proxmox and those same disks adds a layer without solving an obvious problem. Local Proxmox ZFS is usually simpler there.

The plugin makes more sense when TrueNAS is a separate storage system. Picture three Proxmox compute nodes connected to one dedicated TrueNAS appliance. None of the VM storage is local to the compute nodes, and all three hosts need to see the same block storage so workloads can move between them. In that setup TrueNAS is centralized shared storage, a different job from local Proxmox ZFS.

Proxmox can obviously run ZFS. The plugin addresses how easily Proxmox can consume storage managed by another ZFS system, and that's where it earns its place.

Why not just use NFS?

You still can. NFS is one of the simplest ways to connect TrueNAS and Proxmox, and for plenty of small environments it's good enough. Create an NFS dataset, export it, add it as Proxmox storage, and multiple nodes can use it.

The plugin is aimed at administrators who specifically want block storage and more storage-native snapshot behavior. TrueNAS argues that NFS-backed VM disks can carry snapshot costs, because Proxmox commonly relies on QEMU copy-on-write formats on file storage. With large virtual disks, those operations can get slow enough to affect workloads. Block storage avoids that workflow, and the plugin lets TrueNAS handle ZFS snapshots underneath the Proxmox operation, which is much closer to what administrators expect from storage-array integration.

That doesn't make iSCSI automatically better than NFS. NFS is easier to understand and troubleshoot, has less block-storage plumbing, and works well for ISOs, backups, templates, and many ordinary VM workloads. The plugin gets more attractive when snapshot performance, thin provisioning, multipathing, independent virtual-disk management, or high-performance block access matter to you.

TrueNAS itself suggests a mixed design: the plugin for VM block storage, with NFS or SMB on the same system for ISO images, backups, or ordinary file shares.

Why not use normal iSCSI without a plugin?

Plain iSCSI gives you connectivity, but it doesn't automate the storage lifecycle. An iSCSI target presents block devices to Proxmox perfectly well. The trouble starts when you need another block device, because someone still has to create it. In a small lab that's you. In a company it can mean a ticket to the storage team.

The plugin moves that work into Proxmox. When a VM disk is created, the TrueNAS API can create the corresponding zvol and storage mapping. When the disk is deleted, the plugin can remove the backing storage objects. Resizing and snapshots can follow the same pattern. That's much closer to how VMware administrators expect a storage integration to behave.

It also explains why enterprises may care more about this than the first wave of homelab reactions suggested. A homelabber can reasonably say, "I create a zvol once a year. Why do I need an integration for that?" A virtualization team provisioning hundreds of disks would answer differently, because cutting out repetitive storage tickets saves real operational time.

What does NVMe/TCP add?

Lower-overhead block access, which is one of the more interesting parts of the plugin, though it comes with a version requirement. TrueNAS documentation says the plugin supports iSCSI and NVMe/TCP, and NVMe/TCP mode needs Proxmox VE 9.x or later.

That makes the plugin more than an iSCSI automation wrapper. With fast NVMe storage and modern Ethernet, NVMe/TCP can be a more natural path between VM hosts and flash storage than older SCSI-based protocols. The announcement drew interest on exactly this point: several administrators cared less about the GUI integration than about a native third-party storage backend exposing NVMe/TCP to Proxmox.

The usual storage design questions don't go away with a new protocol. Network redundancy, multipathing, and latency all still matter. And if the TrueNAS system is a single-controller box, it can still be a single point of failure. A faster transport won't make a non-HA storage appliance highly available.

Does the plugin make TrueNAS an alternative to Ceph?

It can be an alternative, but it's a different architecture. A typical Proxmox Ceph cluster spreads storage across the Proxmox nodes themselves, so compute and storage are hyperconverged. Lose a storage node and the remaining nodes can keep serving replicated data, provided the cluster was designed with enough failure tolerance.

A TrueNAS-backed design usually separates the layers: Proxmox nodes do compute, TrueNAS does storage. That can be simpler, especially if an organization already owns a substantial storage system or wants compute nodes without large local disk sets. A dedicated system can also deliver very strong storage performance. One administrator in the discussion described using TrueNAS as an MPIO SCSI target over dual 100GbE links because it performed better for their workload than Ceph. That's one deployment's result and shouldn't be read as a universal benchmark.

The architectural tradeoff matters more. With one ordinary TrueNAS box, the storage server becomes a central dependency. TrueNAS Enterprise can provide dual-controller HA on supported enterprise hardware, but Community Edition doesn't turn an arbitrary pair of servers into that storage-controller design. That's why TrueNAS says to treat the plugin as separated compute and storage, not as a hyperconverged Ceph replacement.

If your goal is learning or building Ceph, the Proxmox Health Check is a useful reminder that quorum, storage networking, replica design, and failure domains matter far more than getting the pool to show up in the UI.

Is this plugin production-ready today?

No, not according to current TrueNAS documentation, so read this before you run the GitHub install command. TrueNAS currently labels the Proxmox VE Storage Plugin as:

• in active development
• not fully tested
• intended for TrueNAS Community Edition
• not yet supported on TrueNAS Enterprise systems
• not recommended for production workloads

The September announcement says Enterprise support is in active validation. Read carefully, those statements agree with each other: the code exists, Community Edition users can test it, Enterprise validation is underway, and production support hasn't arrived.

This matters because the setup that benefits most from the plugin, shared storage under multiple virtualization hosts, is also where you should be most conservative. A storage plugin bug can affect VM creation, snapshots, migration, deletion, or access to the underlying volume. Something being on GitHub doesn't mean it's ready for your core production cluster.

TrueNAS recommends testing it on a non-production cluster first, and I'd do exactly that.

What are the security tradeoffs?

The plugin gets its automation by giving Proxmox more authority over TrueNAS. Current TrueNAS documentation requires Proxmox nodes to reach the TrueNAS WebSocket API over HTTPS on port 443 and the storage service over iSCSI on TCP 3260. NVMe/TCP uses its own storage path. The Proxmox storage configuration also holds a TrueNAS API key with enough privileges to create and manage datasets and block-storage resources. That's more trust than a host that can only reach an iSCSI LUN someone already created.

One early worry in the discussion was that the plugin might need SSH access from Proxmox into TrueNAS. Current official documentation doesn't describe SSH as the normal control mechanism; the plugin uses the TrueNAS API. That's better for access control, but the API key is still sensitive. If a Proxmox host is compromised, an attacker may inherit whatever storage-management authority that key carries.

Treat the storage network and management API as infrastructure networks, separate from ordinary client LAN traffic. In practice that means using the narrowest API permissions the plugin supports, restricting which Proxmox nodes can reach the TrueNAS management API, and protecting the storage network separately.

Convenient automation doesn't reduce privilege. It usually works the other way, since the automation account needs enough rights to do the work you no longer do by hand.

What about running TrueNAS as a VM inside Proxmox?

That's a different design from the one this plugin targets. It can work, and plenty of homelabs do it. People pass an HBA or physical disks through to a TrueNAS VM, let TrueNAS own the ZFS pool, then export storage back to other VMs or machines.

The obvious complication is dependency. If Proxmox needs storage from a TrueNAS VM that itself needs Proxmox to boot, startup and recovery order become important. One user in the discussion deliberately kept anything needed to boot Proxmox or critical VMs off the virtualized TrueNAS instance and used it only for bulk data. That's a sensible way to limit the circular dependency.

It still isn't the plugin's strongest use case, which is a dedicated TrueNAS system serving multiple Proxmox nodes. That gives the storage layer its own hardware, lifecycle, network interfaces, and failure boundary.

Who should actually test this plugin?

Three groups should find it interesting right away. First, anyone already running Proxmox with TrueNAS over manually managed iSCSI. The plugin goes straight at work you already know is repetitive.

Second, a VMware migration project where the organization wants Proxmox for compute but doesn't want to redesign storage at the same time. Keeping a separate shared-storage architecture can make the hypervisor move less disruptive.

Third, a lab evaluating block storage over iSCSI or NVMe/TCP before deciding how to build a larger Proxmox environment.

Who probably doesn't need it? A single Proxmox host with local disks and local ZFS, a small lab that's happy with NFS, a cluster designed around Ceph, or someone running TrueNAS only for SMB shares and media files.

The plugin's narrow scope is what makes it useful. It connects two products people already run together and removes a layer of manual storage administration.

Where storage responsibility lives

The argument quickly turns into "TrueNAS ZFS versus Proxmox ZFS," which misses what the plugin is for. Both use OpenZFS and both can manage storage. The difference is where storage responsibility lives.

If the disks belong to one Proxmox host, native Proxmox ZFS is hard to beat for simplicity. If several Proxmox hosts need shared storage from a dedicated TrueNAS system, the plugin makes a lot more sense. And if you need hyperconverged storage that survives compute-node failures without a separate storage appliance, Ceph answers a different problem.

The plugin doesn't remove any of those choices, but it makes one of them much easier to run.

For now, test it and don't bet production on it. If TrueNAS moves the plugin from early-adopter status to a fully supported Enterprise integration, it could become one of the more practical storage options for organizations moving virtualization workloads to Proxmox without rebuilding their storage architecture at the same time.