TrueNAS launches official plugin for Proxmox VE (beta)

Anyone running Proxmox and TrueNAS together knows today’s flow well: you configure the iSCSI target on TrueNAS, point Proxmox at it, create LUNs by hand, manage snapshots in two places, and pray you never need to resize anything in production. It works. But it is manual, painful, and does not scale well. It is the same handcrafted stack I documented in the PBS in LXC with NFS on TrueNAS guide.

iXsystems just launched the official TrueNAS plugin for Proxmox VE in beta. And it changes that flow quite a bit.

What it is and what changes

The plugin installs on each Proxmox node and registers as a native storage backend. From then on it talks to the TrueNAS API, not to iSCSI directly. When Proxmox needs to create a VM disk, the plugin asks TrueNAS to create the corresponding ZVol, publishes it as an iSCSI LUN or NVMe/TCP namespace, and maps it to the target automatically.

In practice: you create the VM on Proxmox, pick TrueNAS storage, and you never need to open TrueNAS at any point. The plugin handles all provisioning on the array.

Same goes for the lifecycle: resize, snapshot, VM migration between hosts. Everything goes through the plugin, which runs the corresponding TrueNAS operations via API.

The part that matters most: instant ZFS snapshots

Before the plugin, anyone keeping VMs on NFS on TrueNAS had each disk as a big QCOW2 file on a network share. A snapshot on Proxmox meant working inside that file. Proxmox’s own documentation warns that for large disks this can take several minutes, in extreme cases hours.

With the plugin the logic changes completely. Each VM disk is an independent ZVol on the array. The snapshot is done by OpenZFS on TrueNAS, not by Proxmox. And a ZFS snapshot copies nothing: it records block state at that moment. The operation is nearly instant regardless of disk size and only consumes space as new writes happen.

That also holds for live snapshots with RAM.

What the plugin delivers in this beta

• Automatic provisioning: create a VM on Proxmox and the ZVol is born on TrueNAS by itself
• Transport: iSCSI and NVMe/TCP, you choose in the config
• Thin provisioning: volumes created on demand, with capacity check first
• Resize: expand disk straight from Proxmox, no TrueNAS login
• ZFS snapshots: instant via OpenZFS, live RAM snapshot included
• Multipathing and CHAP: compatible with common production iSCSI practices
• LXC: manages container root filesystems too, not only VM disks
• Config validation: checks before deploy, with API key auth (retires the root SSH login many ZFS-over-iSCSI setups required)

What is still outside the plugin: ISOs, container templates, and backup dumps stay on NFS or SMB. TrueNAS serves those from the same system and same pool, but over another share. For backup, PBS with offsite destination remains the right piece of the puzzle.

How to install

The plugin requires TrueNAS SCALE 25.10 “Goldeye” or later. Earlier versions are not compatible.

On TrueNAS, the minimum prep is this

You need on TrueNAS:

• A storage pool created
• iSCSI enabled under Shares → Block Shares (iSCSI) → Turn On Service
• An iSCSI portal configured with IP and port
• A user with a generated API key

Store the API key somewhere safe. You will need it for the plugin config.

On Proxmox nodes, install via APT

For Proxmox VE 9.x (Debian Trixie):

bash <(curl -sSL https://raw.githubusercontent.com/truenas/truenas-proxmox-plugin/alpha/install.sh) \
  --non-interactive --apt-install --apt-suite trixie

Install on every node in the cluster.

Confirm connectivity before configuring:

curl -kI https://TRUENAS-IP/
timeout 3 bash -c '</dev/tcp/TRUENAS-IP/3260' && echo 'iSCSI port reachable'

Configuration wizard

After install, download the config script and create an alias to make life easier:

curl -fsSL https://raw.githubusercontent.com/truenas/truenas-proxmox-plugin/alpha/install.sh \
  -o /root/truenas-plugin-install.sh

echo "alias truenas-storage='bash /root/truenas-plugin-install.sh'" >> /root/.bashrc
source /root/.bashrc

Run truenas-storage and pick option 1) Create new storage on TrueNAS (automated provisioning). The wizard asks for:

• Storage name on Proxmox
• TrueNAS IP or hostname
• API port (443 default)
• API key
• Transport mode (iSCSI or NVMe/TCP)
• Dataset name
• IQN (auto-generate or customize)
• iSCSI portal IP
• Block size (16K is the recommended default for VM workloads)

Confirm provisioning and choose which cluster nodes receive the config. The storage shows up available on Proxmox immediately.

Two operating modes

Automated provisioning, for new storage. The plugin creates everything on TrueNAS (dataset, target, extent, mapping). You only fill parameters in the wizard.

Manual (existing storage), for storage you already have configured and want to manage through the plugin. You create the components on TrueNAS (initiator, target, dataset) and enter the names in the wizard. Useful for anyone with LUNs already in production who wants to move to the new flow without recreating everything.

What to watch before production

The plugin is marked as Early Adopters by iXsystems. Community Edition already has access. Enterprise support is still being validated.

Two attention points that already showed up in early community tests:

Snapshots created outside Proxmox cause trouble. If you take a snapshot directly on TrueNAS, via UI or schedule, Proxmox does not know that snapshot exists and Proxmox native snapshot operations can conflict. There is an open PR on GitHub to import TrueNAS-created snapshots into the Proxmox VM config, but it has not been merged yet.

Disk serial on a virtualized VM. If you run TrueNAS as a VM on Proxmox itself (for lab or testing), virtual disks have no serial by default and TrueNAS refuses to create the pool due to duplicate serials. Fix by adding serial=VALUE to each SCSI disk config in the VM file at /etc/pve/qemu-server/VMID.conf.

In my read

I run Proxmox + TrueNAS on several client environments and know well the manual work this stack requires today, especially with more than one node, when you need every host to see the same storage with the same config.

The plugin solves exactly that point: config becomes code managed via API, provisioning is automatic and consistent across nodes, and disk lifecycle stays on Proxmox without opening TrueNAS for day-to-day ops. It is storage with an enterprise feel, without per-core licensing like on proprietary HCI platforms.

The instant ZFS snapshot is the most concrete differentiator. Anyone who has waited minutes for a large disk snapshot knows how much that changes.

But it is beta, and beta gets treated as beta. For now the right place is the lab: install, test both modes, validate snapshot behavior, simulate node failure, watch how the cluster reacts. Follow the issues on GitHub. The project is active and known issues are being addressed fast.

When a final version ships with validated Enterprise support and edge cases resolved — especially external snapshots — this plugin will change a lot of how shared storage is operated on Proxmox. For anyone calculating the real cost of operating outside VMware, it is one less manual line item in the math. It is the kind of integration that should have existed from the start. From now on, it stops being a manual hack and becomes a native flow.