iSCSI vs. NFS for Hypervisor Storage: When What?

If you want to attach a TrueNAS pool as VM storage to a hypervisor (VMware ESXi, Proxmox VE, Linux KVM, Microsoft Hyper-V), the question hits early: iSCSI or NFS? Both work. Both have been in production for years. But the architectures differ fundamentally — and so does the fit for specific workloads.

This article is a pragmatic decision guide. We cover iSCSI (block storage) and NFS (file storage), explain strengths and weaknesses, and give recommendations for the common hypervisor platforms.

The Architecture in One Sentence

• iSCSI: The hypervisor sees a block-device LUN (a virtual disk) and treats it like a local disk. The filesystem (VMFS for VMware, LVM or ext4 for Linux) sits on the hypervisor.
• NFS: The hypervisor mounts a file share from the storage. VM disks are individual files (.vmdk, .qcow2, .raw) inside the NFS directory.

That sounds small — the consequences are large.

iSCSI in Detail

Advantages

Performance on small block I/O. Block storage has no file-locking overhead, no path resolution in a filesystem on the storage path. On many small I/Os (databases, VDI with simultaneous boot storms) iSCSI is traditionally faster than NFS.

Multipathing built in. iSCSI supports MPIO (Multi-Path I/O) — multiple network paths to the same storage, with failover and load balancing. Established on VMware (PSP policies like Round Robin) and Linux (multipathd). See TrueNAS iSCSI Multipath for VMware.

VMFS cluster filesystem. VMware ESXi uses VMFS on iSCSI LUNs — a cluster filesystem that allows several ESXi hosts to write to the same LUN at once. This enables vMotion, HA and DRS without an extra file-locking layer.

Predictable performance. A LUN has a clear size and a clear performance profile. No surprises from “other workloads on the same share”.

Disadvantages

One LUN per VM disk isn’t practical. In large environments with hundreds of VMs LUN management would be overwhelming. Instead: one big LUN, many VMs on it. That makes storage-layer snapshots clumsy — a TrueNAS snapshot of the LUN includes every VM on it.

Cluster coordination required. Several hypervisors on the same LUN need a cluster filesystem (VMFS) or cluster LVM. Without VMFS on Proxmox: one LUN per node, manual failover.

Snapshot restore is harder. If 50 VMs live on a LUN and you want to roll back one VM, you don’t restore the TrueNAS snapshot — you mount it as a read-only clone, read the VM disk out, copy back into the running VMFS.

More setup overhead. iSCSI needs initiator config on every hypervisor, authentication (CHAP), target portal, LUN mapping, multipath. NFS in comparison is “mount the path and go”.

NFS in Detail

Advantages

VMs are files. A .qcow2 or .vmdk file is movable, copyable, individually backupable. That makes storage vMotion and manual migrations easy: mv vm-100-disk-0.qcow2 and done.

TrueNAS-side snapshots are directly accessible. When you take a dataset snapshot and later only need one VM disk back, that’s a simple file access via the hidden .zfs/snapshot/<name>/ path. On iSCSI it would be significantly more work.

Multiple hypervisors without a cluster filesystem. NFS has built-in locking semantics (RPC). Three ESXi hosts can hit one NFS mount concurrently without a VMFS-equivalent. On Proxmox: three nodes mount the same NFS path, and VMs live-migrate — no extra cluster storage layer.

Easy to understand, easy to debug. An NFS share is human-readable. ls on the hypervisor shows the VM disks.

Thin provisioning for free. A .qcow2 file only grows as needed. With iSCSI LUNs thin provisioning has to be configured explicitly on both storage and hypervisor.

Disadvantages

File-locking overhead. Every I/O on an NFS share goes through NFS locking. With many small I/Os this is measurable — even though LAN latency is typically under 1 ms.

A slow share slows all VMs. If one hypervisor saturates the NFS mount with writes, every other hypervisor on the same mount suffers. Isolation is better with separate iSCSI LUNs.

Performance on small synchronous writes. NFS writes with sync=always (sensible for VM storage to guarantee consistency) live on the ZFS SLOG performance. Without a dedicated SLOG NVMe, sync writes are significantly slower than iSCSI with write cache.

Multipathing less straightforward. NFS has no classical MPIO. HA on the NFS side comes via VRRP/CARP on the storage layer (TrueNAS HA pair) or LACP bonds, not via multiple mount paths. Load balancing across links is possible with NFSv4.1 (pNFS) but rare in practice.

ESXi driver quirks. Older ESXi versions had problems with NFSv4 (NFSv3 mandatory or carefully configured NFSv4.1). Largely solved on current ESXi versions, but worth a version check.

Performance Comparison: What Are You Actually Measuring?

Often heard: “iSCSI is 30% faster than NFS.” That’s an over-simplification — the truth is more nuanced:

Sequential reads/writes (backup jobs, video streams): practically no difference. Both saturate 10 GbE about equally. At 25/40/100 GbE the storage pool (disks, ARC) becomes the bottleneck, not the protocol.

Random 4K reads (VDI, databases): iSCSI has a slight edge — typically 5–15% on otherwise equal hardware. At the pool level NVMe vs. HDD, ARC size and SLOG (for sync writes) matter much more.

Random 4K writes (database write load): with sync=always NFS is often slower — SLOG performance limits. With sync=disabled NFS catches up, but that’s risky on power loss.

Mixed VM workloads: in mixed mid-range setups (TrueNAS H or M series + 10/25 GbE) the difference is smaller in practice than forum debates suggest. Pool design (NVMe SLOG, mirror vs. RAIDZ, ARC size) has more impact than protocol choice.

Snapshots: The Underrated Factor

A key architectural difference lives in snapshot behaviour — and that has big consequences for VM storage.

iSCSI snapshots

• TrueNAS snapshot of the LUN covers all VMs on the LUN
• Restoring a snapshot = rolling back the entire LUN → all VMs are reset
• Selective restore of a single VM: clone mount, manual extraction
• Hypervisor-native snapshots (VMware VMSnapshot, Proxmox snapshot) work in parallel but are separate

NFS snapshots

• TrueNAS snapshot of the NFS dataset covers all VM files
• Restore: copy individual .qcow2/.vmdk files back from the .zfs/snapshot/ path directly
• Hypervisor snapshots (VMware VMSnapshot, qcow2 internal snapshots) complement well
• Selective restore is easier

For SMB setups without dedicated storage admins this is a strong argument for NFS — the restore paths are clearer and less error-prone.

See also TrueNAS Snapshot Schedule Best Practices and our specific article on TrueNAS Snapshot Strategies for VM Storage.

Recommendations per Hypervisor

VMware vSphere / ESXi

Historically: iSCSI with VMFS — many legacy environments look like this.

Today: NFS has caught up. vSphere supports NFSv4.1 reliably. Storage vMotion between NFS datastores works, TrueNAS snapshots are easier to access.

Recommendation 2026:

• New setups without FC history: NFS for simplicity, iSCSI with multipath when maximum performance matters
• Legacy environments with working iSCSI/VMFS: don’t migrate without a reason
• NVMe-oF/TCP is the new TrueNAS recommendation for high performance — if ESXi (8.0+) supports it

Proxmox VE

Recommendation: NFS for simplicity. Cluster VMs live-migrate across nodes when they all share the NFS mount.

Alternatively iSCSI with LVM-thin for non-ZFS setups — but you lose the ZFS-snapshot advantages the TrueNAS Proxmox plugin automates.

Since the official Proxmox plugin (TrueNAS 25.10) iSCSI with ZFS-aware snapshots is available from the Proxmox UI. For Proxmox setups that’s a strong argument for iSCSI — the snapshot pain point drops.

Linux KVM (libvirt)

Recommendation: NFS for simple setups, iSCSI with LVM for shared cluster storage (Pacemaker, oVirt).

Microsoft Hyper-V

Hyper-V handles both, but SMB3 is often more natural than NFS — Microsoft has heavily optimized SMB3 for Hyper-V storage. iSCSI with Cluster Shared Volumes (CSV) is the enterprise standard.

NVMe-oF: The Future Makes Both Look Old

iSCSI and NFS were both designed before the SSD era. iSCSI was ratified in 2003, NFSv3 in 1995. With modern NVMe SSDs at microsecond latency both protocols eat a meaningful chunk of theoretical performance.

NVMe-oF (NVMe over Fabrics) — especially NVMe/TCP — addresses this. The protocol speaks NVMe commands directly over the network without iSCSI’s block-layer stack. Result: lower latency, higher IOPS.

• TrueNAS supports NVMe-oF/TCP since 24.10 / 25.04 (see TrueNAS Proxmox plugin)
• VMware ESXi 8.0+ supports NVMe-oF/TCP natively
• Linux kernel supports NVMe-oF/TCP since 5.0

For new all-NVMe storage pools (F series, V series) NVMe-oF/TCP is already the right choice over iSCSI in many setups.

Concrete Decision Matrix

Scenario	Recommendation
Proxmox cluster, small VM count, SMB	NFS
Proxmox cluster with TrueNAS plugin, ZFS snapshots from UI	iSCSI (plugin) or NVMe-oF/TCP
Legacy VMware with VMFS	keep iSCSI
New VMware environment 2026, < 50 VMs	NFS
New VMware environment 2026, > 100 VMs, performance-critical	iSCSI with multipath, mid-term NVMe-oF/TCP
VDI with morning boot storms	iSCSI with multipath or NVMe-oF
Database VMs with sync write load	iSCSI with dedicated SLOG, or NVMe-oF
Backup targets, archive VMs	NFS (simplicity wins)
Hyper-V	SMB3 or iSCSI with CSV

DATAZONE Recommendation

For mid-market setups with TrueNAS + Proxmox our default in 2026:

• NFS as the baseline when you have no special performance demands
• iSCSI with the official TrueNAS Proxmox plugin when you want ZFS snapshots from the Proxmox UI
• NVMe-oF/TCP for new all-NVMe investments (F series, V series all-flash)

For VMware setups the history matters — running iSCSI/VMFS in production: don’t migrate without a reason. Planning new: NFS is in scope, or jump straight to NVMe-oF.

Conclusion

iSCSI and NFS are both production-ready. The difference is less raw performance than storage ergonomics: NFS makes snapshots and per-VM restores easy; iSCSI grew alongside cluster filesystems and multipath.

For most SMB setups the arguments favour NFS — until the official TrueNAS Proxmox plugin enters and largely fixes iSCSI’s historical snapshot weakness.

And for the next 3–5 years: look twice at NVMe-oF/TCP before designing new all-NVMe setups around legacy iSCSI.

Sources and Further Reading

• TrueNAS iSCSI Multipath for VMware
• TrueNAS Proxmox Plugin (official, NVMe/TCP)
• TrueNAS Snapshot Schedule Best Practices
• TrueNAS Snapshot Strategies for VM Storage
• Ceph vs. ZFS — When What?
• TrueNAS Performance Optimisation
• Proxmox Backup Server 4.0 What’s New