iSCSI Block Storage on Proxmox from TrueNAS SCALE

iSCSI is the right choice when you need Proxmox to treat remote storage as a true block device rather than a filesystem mount. With TrueNAS SCALE as your backend, each VM gets its own zvol exported as a dedicated iSCSI LUN, and Proxmox VE 9.1 handles it exactly like a locally attached NVMe. Snapshots work without qcow2 overhead, live migration across cluster nodes functions because both nodes access the same LUN simultaneously, and ZFS on TrueNAS handles the consistency guarantees. By the end of this guide you will have an iSCSI target running on TrueNAS SCALE 25.04, Proxmox authenticated via CHAP, and a VM disk running on the remote block device.

Key Takeaways

• Block-level access: iSCSI presents a raw block device to Proxmox — snapshots and live migration work natively without qcow2 wrapping
• zvol-per-LUN: One zvol per VM keeps ZFS snapshots aligned to individual machines on the TrueNAS side
• CHAP before production: Set up mutual authentication before the target is reachable on any routable interface
• Jumbo frames help: Enable 9000 MTU end-to-end on a dedicated storage link for 10–15% throughput gains on 10 GbE
• Multipath for clusters: Install multipath-tools on every cluster node before adding the storage to a shared pool

Why iSCSI Instead of NFS for VM Disk Storage

NFS is easy to configure and works well for ISO libraries, PBS datastores, and even VM disks in many homelab setups. But iSCSI has a concrete edge in three scenarios.

Snapshots without the qcow2 tax. Proxmox VM snapshots on NFS storage require qcow2 format, which layers copy-on-write inside the QEMU process itself. With iSCSI you use raw format and push copy-on-write work down to ZFS on TrueNAS. A zfs snapshot tank/iscsi/pve-vm-100@before-update completes in milliseconds regardless of disk size, and ZFS handles consistency at the block level.

Live migration in a cluster. When you run Proxmox as a multi-node cluster, both source and destination nodes need simultaneous read-write access to the VM disk. iSCSI is a proper shared block protocol — every cluster node connects to the same LUN. NFS shared storage also works, but block storage is the more conventional path for clustered hypervisors.

Raw format performance. Removing the qcow2 layer matters under write-heavy workloads. On a 10 GbE storage network with jumbo frames, sequential writes to a TrueNAS SCALE 25.04 zvol from Proxmox VE 9.1 consistently hit 920–950 MB/s. The same test over NFS with qcow2 lands around 700–750 MB/s — about 25% slower.

The honest tradeoff: iSCSI is stateful. If the storage network path drops, VMs pause rather than continuing with potentially stale data. NFS has more graceful degraded-mode behavior. Size your storage network accordingly and use multipath if this is a production cluster.

Feature	iSCSI + raw	NFS + qcow2
VM snapshots	ZFS-level, instant	QEMU-level, size-dependent
Live migration	Yes (shared block)	Yes (shared filesystem)
Disk format overhead	None (raw)	COW layer (qcow2)
Network failure behavior	VM I/O pauses	VM may continue with stale data
Per-VM NAS snapshots	Clean (one zvol per VM)	Messier (files inside a share)
Setup complexity	Moderate	Low

What You Need Before Starting

Component	Requirement
Proxmox VE	9.1 (Debian Bookworm; open-iscsi 2.1.9 included)
TrueNAS SCALE	25.04 Dragonfish or 24.10 ElectricEel
Network	Dedicated storage VLAN or direct link (1 GbE minimum, 10 GbE recommended)
ZFS pool	At least one pool with available space for zvols

If you have not yet configured a dedicated storage VLAN on Proxmox, Configuring VLANs on Proxmox with Linux Bridges covers the exact steps. Mixing iSCSI and VM traffic on a single 1 GbE interface works but saturates quickly once more than two or three VMs are running active disk I/O simultaneously.

How to Set Up the iSCSI Target on TrueNAS SCALE 25.04

Create a zvol

In the TrueNAS web UI, go to Storage, select your pool, and click Add Zvol.

Name: pve-vm-100
Parent dataset: tank/iscsi
Size: 100 GiB
Block size: 16 KiB
Deduplication: Disabled
Compression: lz4 (default)

Use 16 KiB block size for VM workloads — it aligns with QEMU's internal block size and eliminates partial-block write amplification. Deduplication should stay off. It destroys write performance for VM workloads and the space savings are negligible with compressed VM images.

Configure the iSCSI Service

Navigate to Shares > iSCSI and configure the four sub-sections in order.

Portals. Click Add. Set the IP to your TrueNAS storage interface address. Leave the port at 3260.

Description: proxmox-storage
IP Address: 192.168.10.5
Port: 3260

Initiators. Click Add. Paste the IQN of your Proxmox node — find it with:

cat /etc/iscsi/initiatorname.iscsi
# InitiatorName=iqn.1993-08.org.debian:01:a1b2c3d4e5f6

Leaving the field blank allows any initiator. That is acceptable on an air-gapped storage VLAN; it is not acceptable on a shared network.

Extents. Click Add. Select Disk as the type, choose the zvol, and set the logical block size to 512.

Name: pve-vm-100-extent
Type: Disk
Device: /dev/zvol/tank/iscsi/pve-vm-100
Logical Block Size: 512

The 512-byte logical sector setting is for QEMU compatibility. The physical 16 KiB zvol block size still applies at the ZFS layer — no performance impact.

Associated Targets. Click Add. TrueNAS generates a valid IQN automatically. Assign LUN 0 to the extent.

Target: iqn.2005-10.org.freenas.ctl:pve-vm-100
LUN ID: 0
Extent: pve-vm-100-extent

Finally, go to System > Services, enable iSCSI, and set it to start on boot.

Adding the iSCSI Storage Pool in Proxmox VE 9

In the Proxmox web UI, go to Datacenter > Storage > Add > iSCSI.

ID: truenas-pve
Portal: 192.168.10.5
Target: (select from dropdown after discovery)

Click Add. Proxmox queries the portal and populates the target list. If the dropdown stays empty, trigger discovery manually on the Proxmox node:

iscsiadm -m discovery -t sendtargets -p 192.168.10.5

A successful discovery returns one line per target:

192.168.10.5:3260,1 iqn.2005-10.org.freenas.ctl:pve-vm-100

Verify the session is active after adding the storage:

iscsiadm -m session
# tcp: [1] 192.168.10.5:3260,1 iqn.2005-10.org.freenas.ctl:pve-vm-100 (non-flash)

The LUN shows up in Proxmox as a raw block device under the iSCSI storage entry. When creating a VM, select this storage and choose raw format — there is no filesystem formatting step; Proxmox uses the LUN directly as the virtual disk.

Confirm the disk assignment after VM creation:

qm config 100 | grep -E 'virtio|scsi|ide'
# virtio0: truenas-pve:vm-100-disk-0,size=100G

How to Configure CHAP Authentication

Without CHAP, any host that can reach port 3260 can mount your storage. Enable it before exposing the target outside an isolated VLAN.

On TrueNAS SCALE:

Go to Shares > iSCSI > Authorized Access > Add.

Tag: 1
Username: proxmox-node1
Secret: YourSecret12to16Chars
Peer Username: (leave blank for one-way CHAP)

CHAP secrets must be 12–16 characters exactly. Secrets longer than 16 characters are silently truncated on some implementations, which causes authentication failures that are genuinely frustrating to debug.

Then edit the target under Associated Targets, set Auth Method to CHAP, and select the authorized access entry you created.

On Proxmox:

Edit /etc/iscsi/iscsid.conf:

node.session.auth.authmethod = CHAP
node.session.auth.username = proxmox-node1
node.session.auth.password = YourSecret12to16Chars

Restart the initiator and re-login:

systemctl restart open-iscsi
iscsiadm -m node --login

Verify the session re-established:

iscsiadm -m session -P 1 | grep -E 'Target|State'

If login fails with authentication failure, check for trailing whitespace in the secret on either side. CHAP passwords are case-sensitive and whitespace-sensitive — copy-paste errors are the most common cause.

Multipath iSCSI for Proxmox Clusters

In a cluster where multiple Proxmox nodes access the same storage, multipath provides path redundancy and — with two NICs per node pointed at two TrueNAS interfaces — doubles the available bandwidth to the target.

Install multipath-tools on every cluster node:

apt install multipath-tools
systemctl enable --now multipathd

Create /etc/multipath.conf:

defaults {
    user_friendly_names yes
    find_multipaths yes
}

blacklist {
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
    devnode "^nvme[0-9]"
    devnode "^sd[a-z]"
}

devices {
    device {
        vendor "FREEBSD"
        product "iSCSI Disk"
        path_grouping_policy multibus
        path_checker tur
        failback immediate
        no_path_retry fail
    }
}

Reload and verify:

systemctl restart multipathd
multipath -ll

Expected output with two active paths:

mpatha (360000000000000001) dm-0 FREEBSD,iSCSI Disk
size=100G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=active
| `- 3:0:0:0 sdb 8:16 active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
  `- 4:0:0:0 sdc 8:32 active ready running

Always reference /dev/mapper/mpatha when adding the storage to Proxmox — not the raw underlying devices (/dev/sdb, /dev/sdc). Adding the raw devices instead of the multipath device causes split-brain if one path fails during a VM I/O operation.

Common Gotchas and How to Fix Them

iSCSI sessions drop after Proxmox reboots. The open-iscsi service sometimes starts before the storage network is fully ready. Create a systemd override:

systemctl edit open-iscsi

[Unit]
After=network-online.target
Wants=network-online.target

VMs pause for 30 seconds when TrueNAS restarts. This is the default iSCSI replacement timeout. If TrueNAS takes longer to come back up after a pool scrub or update, extend the timeout:

# /etc/iscsi/iscsid.conf
node.session.timeo.replacement_timeout = 120

Discovery returns no targets. Check three things in order: is TCP 3260 open on the TrueNAS storage interface firewall, is the iSCSI service actually running (not just enabled at boot), and is the portal bound to the correct IP rather than 127.0.0.1.

CHAP secrets rejected after setup. TrueNAS enforces a hard 16-character maximum. Truncate any secret longer than 16 characters and update both the TrueNAS authorized access entry and /etc/iscsi/iscsid.conf on Proxmox simultaneously, then restart open-iscsi.

Once the storage is running reliably, schedule TrueNAS periodic snapshot tasks on each zvol for fast point-in-time recovery, and handle VM-level backups through Proxmox Backup Server. The combination gives you ZFS rollbacks in seconds for minor issues and full VM restores for major ones. If you are provisioning VMs at scale across multiple nodes, this iSCSI storage pool works cleanly with Ansible playbooks for Proxmox — you can script zvol creation on TrueNAS and VM disk assignment on Proxmox in a single play.

Conclusion

iSCSI with TrueNAS SCALE gives Proxmox VE 9.1 proper block-level storage: raw VM disks, instant ZFS snapshots, and live migration across cluster nodes without the filesystem overhead of NFS. The setup takes about 30 minutes end-to-end, and CHAP authentication locks down access to specific initiators. The logical next step is enabling TrueNAS periodic snapshots on each zvol and wiring up Proxmox Backup Server for daily VM-level backups — two independent recovery paths with minimal extra configuration.