Proxmox VE and TrueNAS have been the two halves of a common homelab shape for years: compute on one box, disks on another. The joint between them has always been slightly homemade. On 11 September TrueNAS published an official answer: a Proxmox VE storage plugin that registers the array as a native storage backend, so provisioning, snapshots, resizing, migration and deletion of VM disks happen from the Proxmox side, over iSCSI or NVMe/TCP, without hand-wiring targets.
The joint it fixes
Putting VM disks on a NAS has always been one of two chores. On NFS, snapshots run through QEMU’s copy-on-write files, can block the VM while they happen, and on large disks take “several minutes, or in extreme cases, even hours,” Proxmox’s own docs say. Hand-cut iSCSI LUNs avoid that specific cost but bring their own: no native snapshot support at all before Proxmox VE 9, and every storage change becomes a change request: a new zvol, a new extent, a new LUN mapping, a wait. Both routes are legitimate and well-worn; neither is what you would design today. TrueNAS’s summary of the plugin is one line: “You click the button. TrueNAS builds the disks.”
What changes
On TrueNAS 25.10 or newer, the plugin registers itself, and every VM disk request becomes an automated zvol, published as an iSCSI LUN or, on Proxmox 9.x, an NVMe/TCP namespace. Snapshots are OpenZFS snapshots that appear as ordinary Proxmox snapshots, live VM-state ones included, and disks are thin, sparse volumes created on demand. The GitHub README adds the details you would otherwise discover in a forum thread: block-backed container rootfs for LXC, iSCSI multipath and optional CHAP, grow-only resize with pre-flight space checks. Clones, moves, backups and imports stay host-side, so plan those the way you already do. Installation follows how Proxmox shops work: a signed APT repository (bookworm for PVE 8, trixie for PVE 9) with automatic version detection, a cluster-aware installer with health checks and rollback, or a standalone .deb for air-gapped nodes.
The honest fine print
This one ships to the Early Adopters channel, Community Edition first, with Enterprise support “in active validation and orderable.” TrueNAS’s own framing line is the one to keep: separated compute and storage, not a hyperconverged Ceph substitute. And if several Proxmox clusters point at one TrueNAS, plan one dataset and one target per cluster.
My read
If your hand-cut iSCSI setup works, nothing here tells you to rip it out — but the wiring this automates was never hard, just tedious and easy to get subtly wrong, and storage incidents live in exactly that margin. The part worth noticing is the shape of the move: TrueNAS adopting Proxmox’s storage API properly, from its own side, rather than leaving it to a community script, and it arrives while Proxmox is one of the landing spots for teams leaving VMware behind. The two platforms just made each other’s jobs easier. Early adopters first is the honest label. Read the setup docs before the cluster finds out the hard way.
Sources: the TrueNAS plugin announcement, the plugin documentation, and the GitHub repository