The earlier SMB/NFS shares guide covered file-level sharing, but for VM storage specifically, block-level access via iSCSI offers a genuinely different performance profile — presenting TrueNAS storage to Proxmox as if it were a raw, locally-attached disk rather than a network file share, often with meaningful performance advantages for VM workloads.

File-Level vs Block-Level Storage

NFS (covered in the earlier shares guide) provides file-level access — Proxmox interacts with VM disk images as files sitting on a network filesystem. iSCSI instead provides block-level access — TrueNAS presents a raw block device over the network, and Proxmox formats and manages it directly as if it were a physically attached drive, generally with less protocol overhead for the kind of random I/O patterns VMs typically generate.

Why Consider iSCSI Over NFS for VM Storage

• Generally lower latency for VM workloads – block-level access typically involves less overhead than file-level network protocols for the small, random I/O patterns typical of VM disk activity
• Works well with Proxmox’s LVM storage backend – iSCSI targets integrate cleanly with Proxmox’s LVM-based shared storage option, a well-established pattern for shared VM storage
• More predictable performance characteristics – without a filesystem layer between Proxmox and the raw blocks, behavior is often more consistent under heavy simultaneous VM I/O

When NFS Remains the Simpler Choice

iSCSI’s block-level nature means less flexibility for some operations NFS handles more naturally — browsing files directly, or using TrueNAS’s own snapshot and replication tools (covered in the earlier replication guide) with the same file-level granularity NFS-stored VM images allow. For many homelab setups, NFS’s simplicity remains entirely adequate, with iSCSI’s advantages becoming more relevant specifically as VM count and I/O demands grow.

Creating a Zvol for iSCSI

Unlike NFS shares, which serve a regular dataset, iSCSI requires a “zvol” — a ZFS volume presented as a block device rather than a filesystem:

1. In TrueNAS Scale, go to your pool and click Add Zvol.
2. Name it and set the size, allocating space specifically for this block device.
3. Configure Sparse provisioning if you want thin-provisioning (the zvol reports its full configured size but only consumes actual space as data is written) rather than reserving the full size upfront.

Configuring the iSCSI Service

1. Go to Shares → Block Shares (iSCSI).
2. Under Portals, create a portal defining which network interface/IP the iSCSI service listens on.
3. Under Initiators, define which clients (your Proxmox nodes) are permitted to connect — either by IP or a more specific initiator identifier for tighter access control.
4. Under Targets, create a target associating your portal and initiator group together.
5. Under Extents, create an extent pointing at the zvol you created, which is what actually gets presented as a block device to connecting clients.
6. Under Associated Targets, link your target and extent together, completing the chain from network-facing target to the actual underlying zvol.

Enabling the iSCSI Service

Ensure the iSCSI service itself is running and set to start automatically:

1. Go to System Settings → Services.
2. Enable iSCSI, setting it to start on boot.

Connecting Proxmox to the iSCSI Target

1. In the Proxmox web interface, go to Datacenter → Storage → Add → iSCSI.
2. Enter your TrueNAS system’s portal address.
3. Proxmox discovers available targets; select the one you configured.

Adding LVM on Top of the iSCSI Target

For a shared storage pool usable across multiple Proxmox nodes in a cluster (relevant to the earlier live migration and HA guides), add an LVM storage backend on top of the iSCSI connection:

1. Go to Datacenter → Storage → Add → LVM.
2. Select the iSCSI-based storage as the base, letting Proxmox manage VM disks as logical volumes within that shared block storage.

Security Considerations

Unlike NFS’s typically simpler network-based trust model, iSCSI supports CHAP authentication for an additional access control layer — worth configuring specifically if your iSCSI traffic isn’t already isolated on a dedicated, trusted storage VLAN (following the segmentation principles covered in the earlier VLAN guide).

Network Considerations

Given iSCSI’s block-level, latency-sensitive nature, running it over a dedicated, fast network connection (the bonding or 10GbE setups covered in earlier guides) rather than sharing bandwidth with general network traffic meaningfully affects real-world VM storage performance — genuinely worth the dedicated network segment if you’re pursuing iSCSI specifically for its performance advantages over NFS.