TrueNAS iSCSI Multipathing for VMware vSphere

If you are running production VMware workloads on TrueNAS in 2026, you should not be using a single iSCSI path. A failed SFP+ transceiver, a switch firmware reboot or an unplugged DAC cable is enough to push every VM on the datastore into an all-paths-down state. Multipath I/O, short MPIO, solves this at the storage layer — cleanly configured, without LACP, without MC/S and without vendor-specific drivers.

This article shows how to build a true active multipath connection between TrueNAS SCALE 25.04 and VMware vSphere 8 U3. We cover the TrueNAS side with portal binding and target configuration, the ESXi side with static targets and path selection policy, plus verification via vmkping and per-path IOPS tuning.

Why MPIO and not LACP?

In SMB environments the question keeps coming up: why not simply bond two 10GbE ports on TrueNAS and let ESXi handle the rest? The answer lies in hashing. LACP distributes data streams based on source/destination tuples. A single iSCSI session between an ESXi initiator and a TrueNAS target always produces the same tuple — so all traffic ends up on one physical link. The second wire is pure standby.

True multipathing instead separates paths logically: each ESXi VMkernel adapter talks to a dedicated TrueNAS portal over its own subnet. The result is two independent TCP sessions that the VMware Native Multipathing Plugin feeds in parallel using Round Robin. If a link fails, path monitoring kicks in within a fraction of a second, and the VMs never notice.

TrueNAS side: portal with two IPs

On the TrueNAS system you configure two dedicated storage networks. A proven scheme uses non-routable /29 subnets per path, each connected to its own physical switch. Example:

Component	Path A	Path B
TrueNAS NIC	enp4s0f0	enp4s0f1
TrueNAS IP	10.20.10.10/29	10.20.20.10/29
Switch	Core-A	Core-B
ESXi vmk	vmk2	vmk3
ESXi IP	10.20.10.20/29	10.20.20.20/29
MTU	9000	9000

In the web UI navigate to Shares — Block Shares (iSCSI) — Portals and create a portal that lists both IPs. Important: this is ONE portal with two addresses, not two separate portals. Discovery Auth typically stays “None” for internal paths, CHAP only for multi-tenant setups.

Next, under Targets, define a new target and assign it exactly to this portal and to the prepared initiator group of your ESXi cluster. As the extent, use a ZFS volume (zvol) with a logical block size of 16K, ideal for mixed VM workloads.

zfs create -V 4T -b 16K -o compression=lz4 -o sync=always tank/iscsi-vmw01

The sync=always option is mandatory with VMware: without it, TrueNAS acknowledges writes before they are persistent in the pool, which can leave VMDKs inconsistent after a power loss. In return you need a fast SLOG device, such as an Optane or enterprise NVMe with power-loss protection.

ESXi side: VMkernel and port binding

On each ESXi host you create one VMkernel adapter per path with iSCSI service enabled. Each vmk adapter is assigned exactly one physical uplink in its port group — the others are set to “Unused” under “Override”. This is the prerequisite for correct port binding and prevents ESXi from collapsing both paths onto a shared uplink.

Then enable the Software iSCSI Adapter and explicitly bind vmk2 and vmk3 to it. Under Static Discovery enter both TrueNAS portal IPs — not via Dynamic Discovery, but each IP individually, so ESXi immediately sees two paths to the same target.

Before the rescan, verify L2 reachability of each path with jumbo frames:

vmkping -I vmk2 -d -s 8972 10.20.10.10
vmkping -I vmk3 -d -s 8972 10.20.20.10

If both tests respond successfully, MTU and VLAN configuration are correct end to end. If one fails, the problem is almost always at the switch port or in a wrong MTU on the vSwitch — never directly at the TrueNAS portal.

Path Selection Policy: Round Robin with IOPS tuning

After the rescan, the datastore shows two paths. By default VMware often sets the policy for generic iSCSI targets to “Most Recently Used” (MRU) — meaning one active path and one standby. For TrueNAS, switch to Round Robin (VMW_PSP_RR), ideally via a claim rule so new LUNs are bound correctly automatically.

The second step is the per-path IOPS limit. The default is 1000 I/Os per path before ESXi switches — too high for latency-sensitive VMs. With 10GbE multipath, a value of 1 has proven effective:

esxcli storage nmp psp roundrobin deviceconfig set \
  --device=naa.6589cfc000000xxxxxxxxxxxxxxxxxxx \
  --iops=1 --type=iops

This causes ESXi to alternate every single I/O across both paths. The CPU overhead is negligible on modern Xeon or EPYC hosts, while the throughput gain under load is clearly measurable. More background on tuning decisions like this can be found in our virtualization consulting.

Verification and failover testing

Before going into production, every MPIO setup belongs on the test bench. A realistic test protocol covers:

Test	Method	Expectation
Both paths active	esxcli storage nmp device list	State: active for vmhba64:C0:T0 and C1:T0
Load distribution	esxtop — u, F — path stats	Both paths carry IOPS
Switch failure A	Reboot core switch A	No VM hang, path A goes “dead”, B carries 100%
TrueNAS NIC failover	Pull cable on enp4s0f0	Identical behavior, alarmed path
Recovery	Reconnect cable/switch	Path returns to “active” automatically

With a clean setup, failover time stays below two seconds — well within typical VM timeout thresholds. If you want a graphical view of path utilization, you can also connect TrueNAS to a central monitoring stack via SNMP or NetData.

Common pitfalls

In practice we keep seeing the same mistakes: VMkernel adapters with multiple active uplinks, shared subnets for both paths, missing jumbo frame configuration on switch trunks, or a TrueNAS pool without SLOG while sync=always is active. CHAP configurations that are present on only one side also lead to sporadically “dead” paths that ESXi then refuses to reactivate for minutes.

Another classic is the assumption that MPIO automatically covers the backup path as well. It does not — Veeam or Proxmox Backup streams use separate sessions and need their own concept, for example a dedicated storage network split or a separate backup portal.

Conclusion

Multipath I/O on TrueNAS is achievable with manageable effort and lifts the availability of your VMware storage connection to the level production workloads demand in 2026. Two subnets, two switches, two VMkernels — that is all it takes for true link redundancy and doubled throughput.

DATAZONE supports you with planning, implementation and failover testing of your TrueNAS-VMware storage architecture — from selecting NIC and SLOG hardware to commissioning in your production cluster. Get in touch if you want to take your storage availability to the next level.