senn-techsenn-tech
Storage
Storage2026-09-15· By Franz Senn

The TrueNAS Plugin for Proxmox: Official ZFS over iSCSI, Still Not Production Ready

Anyone who feeds Proxmox clusters from a NAS over iSCSI knows the ritual behind every virtual disk: create a zvol on the TrueNAS side, wrap it in an extent, attach it to a target, log the LUN in on the node. And when anything changes, run the lap again. TrueNAS has now published its own plugin to end that loop. The announcement promises that Proxmox can provision, snapshot, resize, migrate and delete TrueNAS-backed VM disks directly, with no manual LUN management at all. That reads like ZFS over iSCSI, finally made official. We read the source code instead of the billboard. State of play, 15 September 2026.

What the plugin actually does

The basis here is the source itself: TrueNASPlugin.pm, roughly 290 KB of Perl under GPL-3.0, maintained under the TrueNAS organisation on GitHub. In short:

  • The control plane is the TrueNAS WebSocket API. For every VM disk the plugin creates a zvol under a chosen dataset (pool.dataset.create), an iSCSI extent on top of it (iscsi.extent.create), and maps everything to a single shared target. The plugin assigns LUN numbers itself; in Proxmox the volumes show up as vol-<name>-lun<n>.
  • The data plane is plain, standard iSCSI. Each Proxmox node runs discovery and login via iscsiadm and addresses the disk through its by-path device. Multipath is on by default, CHAP is optional. NVMe/TCP is available as an alternative, which requires Proxmox 9.x and TrueNAS SCALE 25.10 or newer.
  • Snapshots are real ZFS snapshots on the zvol (pool.snapshot.create). That is the genuine gain over NFS and file storage: where a big NFS disk can block VM I/O during a snapshot, this is a copy-on-write operation on the array, done in seconds, rollback included.

So functionally: the classic ZFS-over-iSCSI architecture with API automation bolted on top. Nothing fundamentally new, but done carefully and maintained by a vendor for the first time. Proxmox itself now uses the category literally: the 9.2 changelog lists TPM state on iSCSI and "ZFS over iSCSI" storages as newly supported.

Three layers, one commandPVE nodeqm and pvesmTrueNAS APIzvol, extent, LUNZFS poolzvols with snapshots
The command goes to the API; the disk data takes a separate iSCSI path. (Quelle: Our own analysis of the plugin source)

The pattern is not new

"ZFS over iSCSI" is the name of a community plugin that has existed for years: freenas-proxmox under AGPL-3.0, actively maintained, latest release v4.0.1 (2 September 2026). Both plugins coexist today, and nobody has declared one the successor of the other. They do share one constraint: TrueNAS is retiring the old REST interface, deprecated from SCALE 25.04 and gone in 26.x, so both had to move to WebSocket.

TrueNAS pluginfreenas-proxmox
Maintained byTrueNAS (contract development, one lead developer)Community
LicenseGPL-3.0AGPL-3.0
NVMe/TCPyes (SCALE 25.10+, PVE 9.x)no
TrueNAS versions25.10 or newer onlyolder releases supported too
Latest statev2.1.23-beta3 (11 Sep 2026)v4.0.1 (2 Sep 2026)

What survives contact with the marketing

Four claims from the announcement, checked against code and documentation:

  1. "Live snapshots including RAM." The wording does not hold. RAM does not go into the ZFS snapshot; the PVE core writes it to a separate vmstate volume (tn_vmstate_storage shared or local in the plugin). Live snapshots work on Proxmox 9, that is a PVE feature and not TrueNAS magic. The volume chains underneath are still a tech preview on the Proxmox side.
  2. "Migrate." That is ordinary shared-block live migration, working because every node sees the same LUN. No plugin code involved. Moving a single disk between storages currently does not work at all, there is an open issue for it.
  3. "Clones." Full clones copy byte by byte. ZFS clones exist in the code, but PVE bypasses the clone paths of external block storages, and the vendor's own limitations page warns of "No Fast Clone Support".
  4. "Delete without leftovers." If a clone fails or a destroy aborts, orphaned zvols stay behind in the dataset and block VMID reuse. The limitations page ships the cleanup recipe along with the warning.

Where it stands: built well, officially beta

The good first: the architecture is clean, and real ZFS snapshots are exactly what NFS-backed Proxmox storage always lacked. Also a fact, and not our judgement but the vendor's own:

  • The TrueNAS documentation says it verbatim: active development, not fully tested, Community Edition only, do not use in production workloads. Enterprise systems are not supported.
  • The issue tracker (38 open on 15 Sep 2026) includes "VM disk on NVME-tcp corruption", NVMe-oF errors on large I/O under load, storage going silently dead after about 30 days because an expired API session stays open, and the HA manager refusing the storage as unsupported. Plus CHAP problems on 25.10 and broken cloud-init detection after clones.
  • Bus factor of one: maintenance runs almost entirely through a single external developer (331 of 381 commits).
  • Version churn: v2.1.5 (June) to v2.1.23-beta3 (11 September), with six published builds between 24 August and 11 September alone.

What we make of it

Our production stack stays as it is: DRBD and LINSTOR as shared storage, Vitastor still under watch (field test), TrueNAS remaining our file server (field report). What changes: if you run a TrueNAS as your central storage, want snapshots driven from the array side and can live with a beta, there is finally a clean path without LUN handwork. In our environment that means the homelab, not the industrial cluster. We will test it there against this list:

  1. Versions first: SCALE 25.10 or newer, PVE 9.x, plugin from the signed APT repository.
  2. The standard lap: create, live snapshot, rollback, resize, destroy, with no orphans left behind.
  3. Kill the API session under load: does the 30-day failure need time, or does a dropped connection trigger it too?
  4. vzdump on LXC (a documented vzdump collision) and destroy after an aborted clone.
  5. Measure snapshot I/O behaviour against NFS snapshots: does the copy-on-write variant actually spare the guest?

We will not put it into production until two conditions are met: the production warning has to leave the documentation, and the corruption issue has to be closed. If the vendor works through its tracker, the direction is right for everyone whose storage already is a TrueNAS.

Further reading

Questions?
Is the new TrueNAS plugin for Proxmox the same thing as ZFS over iSCSI?+

Architecturally, yes: every VM disk is a zvol on the TrueNAS, exported as its own iSCSI LUN, and snapshots are native ZFS snapshots of those zvols. What is new is the automation of the control plane through the TrueNAS API, plus optional NVMe/TCP. The pattern itself comes from the community plugin freenas-proxmox, which has solved the same problem for years.

Can I run production VMs on this plugin today?+

Not by today's standard. TrueNAS itself warns against production workloads in its documentation, supports the Community Edition only, and states the plugin has not been fully tested. Open issues include data corruption over NVMe/TCP, storage going dead after roughly 30 days, and the HA manager rejecting the storage as unsupported.

Does the official plugin replace the older freenas-proxmox?+

No, both exist side by side with no formal succession statement. The community plugin under AGPL-3.0 is actively maintained (v4.0.1, 2 September 2026) and still covers older TrueNAS releases. The official plugin requires SCALE 25.10 or newer but adds NVMe/TCP and vendor maintenance. Both had to move to the WebSocket API because TrueNAS is retiring the old REST interface.