NFS vs. iSCSI for VMware ESXi: A Practitioner's Guide to Architectural Decisions

Choosing between NFS and iSCSI for ESXi shared storage is one of those decisions that looks simple on paper and gets complicated fast once you factor in your actual array, network, licensing tier, and operational team. Both protocols run over standard Ethernet, both are well supported in vSphere, and both can deliver excellent performance the “right” answer depends heavily on context. This guide breaks down the technical differences that actually matter for architectural planning, not just the textbook feature list.

How NFS Works in ESXi

NFS is a file-level protocol. The ESXi host acts as an NFS client and mounts an export from an NFS server (a NAS, filer, or software-defined storage appliance) directly into the hypervisor’s namespace. VMDKs, configuration files, snapshots, and ISOs all live as regular files on that remote file system — there’s no VMFS layer involved, because the array’s own file system (WAFL, ZFS, etc.) is doing the work.

ESXi supports two client implementations side by side:

NFS v3 — stateless, uses a single TCP connection per mount, and has been the default for most deployments for close to two decades.
NFS v4.1 — stateful, adds session trunking (its version of multipathing), Kerberos authentication (krb5 and krb5i), and simplified firewall handling via a single port.

You pick the version at datastore-creation time, and <cite index=”12-1″>you should use the same NFS version for mounting the NFS datastore across all ESXi hosts, since mixing versions on the same datastore can lead to data corruption</cite>.

How iSCSI Works in ESXi

iSCSI is a block-level protocol. It encapsulates SCSI commands inside TCP/IP packets, presenting a raw LUN to the ESXi host exactly as a Fibre Channel LUN would. ESXi formats that LUN with VMFS, VMware’s clustered file system, which is what actually provides multi-host concurrent access, file locking, and the datastore abstraction you interact with in vCenter.

Three initiator types are supported:

Software iSCSI — the ESXi kernel’s built-in initiator, using a standard NIC. Cheapest option, adds a small CPU tax.
Dependent hardware iSCSI — a NIC with an iSCSI offload engine that still relies on ESXi networking configuration.
Independent hardware iSCSI (HBA) — a dedicated card that handles the entire iSCSI stack and networking itself, offloading CPU fully.

Architectural Implications

This file-vs-block distinction cascades into almost every other comparison point below. Because NFS delegates file-system responsibilities to the array, the array vendor’s data services (dedupe, compression, snapshots, replication) tend to be more directly exposed and more granular — you can often see and manage individual VMDK files from the array side. Because iSCSI hands ESXi a raw LUN, VMFS’s own locking and space-management mechanisms take over, which historically made VAAI primitives (hardware-accelerated clone, zero, and locking operations) more mature on the block side, though NAS VAAI has closed much of that gap on capable arrays.

2. Performance Characteristics

Throughput and Latency

The honest, current answer: for a well-configured, modern all-flash array, NFS and iSCSI perform close enough to each other that protocol choice rarely decides your performance ceiling. The network, the array’s controller/cache architecture, and disk media dominate. That said, some patterns show up consistently in independent testing:

In a controlled ESXi 8.0 U1 test against a Synology NAS, <cite index=”1-1″>VM power-on and VMware Tools upgrade operations showed no meaningful difference between NFS and iSCSI, while a robocopy test with many small files completed roughly two minutes faster on iSCSI than on NFS</cite> — a workload-dependent result, not a universal rule.
A separate side-by-side test using matched hardware and MTU 9000 on both protocols found nearly identical read and write throughput between iSCSI and NFS<cite index=”2-1″> datastores backed by the same storage device and same network interfaces</cite>.
Older community testing on NetApp filers found NFS ahead of iSCSI in random read/write and mixed workloads by as much as 20%, with iSCSI only pulling ahead on pure sequential reads<cite index=”5-1″></cite> — a useful reminder that array-vendor NFS implementations (especially NetApp’s, which co-developed much of the NFS/VAAI-NAS spec with VMware) can outperform generic assumptions.

Practical takeaway: don’t pick a protocol based on a vendor’s marketing throughput number. Benchmark your actual array, your actual network path, and your actual workload profile (small-file-heavy vs. large sequential vs. random OLTP-style I/O) before committing at scale.

VAAI and Cloning Performance

This is where the two protocols diverge more clearly. In one lab comparison, iSCSI-backed VAAI clone/move operations dramatically outperformed NFS with VAAI-NAS enabled, to the point that the author <cite index=”3-1″>was very impressed by the iSCSI performance for clones and moves when using VAAI and had assumed NFS performance with VAAI enabled would have been much closer to the iSCSI numbers</cite>. If your workflow leans heavily on linked clones, rapid VM provisioning, or frequent Storage vMotion, this is worth benchmarking specifically rather than assuming parity.

Scalability Limits

NFS v3 has no native multipathing <cite index=”13-1″>it uses a single TCP connection for I/O, so ESXi supports I/O on only one IP address or hostname for the NFS server and does not support multiple paths</cite> at the protocol level (you can still get redundancy via NIC teaming/LACP, just not true multipath load balancing).
NFS v4.1 closes this gap with session trunking: <cite index=”14-1″>the NFS 4.1 client selects paths in round-robin fashion from a list of active paths, removing a path from that list if it goes down until connectivity is restored</cite>.
iSCSI has supported native multipathing (MPIO) with Round Robin, Fixed, and Most Recently Used path-selection policies since early ESXi releases, and combines well with VMFS’s clustered locking for large, multi-host, multi-LUN deployments.
Both protocols are subject to VMware’s published Configuration Maximums (concurrent Storage vMotion counts, datastore counts, LUN/export counts, etc.), which change by release — always check the current Configuration Maximums tool for your exact ESXi build rather than relying on a cached number.

3. Operational Considerations

Setup Complexity

	NFS	iSCSI
Initial config	Mount export via IP/hostname + path; minimal ESXi-side setup	Configure software/hardware initiator, iSCSI targets, discovery (dynamic or static), and format VMFS
Networking	Standard IP networking; NFS 4.1 adds Kerberos/AD integration complexity	Dedicated VLAN/subnet strongly recommended; CHAP auth setup
Multipathing	NFS v3: none natively (NIC teaming only). NFS v4.1: session trunking, multiple IPs specified at mount time	Native MPIO; well-documented Round Robin policy setup
Troubleshooting familiarity	Feels like managing a file share; approachable for teams with Linux/NAS background	Feels like managing a SAN; approachable for teams with block-storage/Fibre Channel background

For a team that’s already comfortable with block storage concepts (LUN masking, zoning-adjacent thinking, MPIO policies), iSCSI setup is second nature. For a team more familiar with file shares and array-side snapshots, NFS setup and troubleshooting will feel more intuitive.

Ongoing Management

NFS datastores expose VM files directly on the array’s file system, which is genuinely convenient for backup software, forensic recovery, and browsing you can often see .snapshot directories or equivalent directly. One long-time NetApp user summed up a common sentiment: <cite index=”5-1″>NFS access has been stable and performance-friendly, with the added advantage of not needing extra licensing to restore backups since snapshot copies are directly accessible</cite>.

iSCSI/VMFS management is more “SAN-like” LUN provisioning, VMFS extent management, and datastore expansion follow familiar block-storage patterns that many enterprise storage teams already have runbooks for.

Troubleshooting Approach

NFS troubleshooting commonly involves checking VAAI status, root-squash settings, export permissions, and — for NFS 4.1 — Kerberos principal/keytab validity and portmapper/mountd service health for v3<cite index=”18-1″></cite>.
iSCSI troubleshooting commonly involves verifying CHAP credentials, MTU consistency end-to-end for jumbo frames, discovery/session state, and MPIO path status via esxcli storage nmp.

Version-Specific Notes (ESXi 7.x / 8.x)

<cite index=”9-1″>NFS v4.1 supports multipathing with multiple connections for better load balancing, but your NFS target must support it</cite> — this is not automatic on every array.
Official nconnect support (multiple TCP connections per mount for NFS v3) was added in vSphere 8.0 Update 2, with NFS v4.1 nconnect support following in Update 3 — a meaningful throughput improvement for NFS v3 environments that previously were capped to a single TCP session<cite index=”11-1″></cite>. If you’re planning new NFS deployments on 8.x, patch to at least U2/U3 before assuming NFS v3 is throughput-limited by design.
NFS v3 and v4.1 use different locking models — <cite index=”11-1″>v3 uses client-side locking while v4.1 uses server-side locking</cite> — which affects behavior during network partitions and host failures.
On the iSCSI side, ESXi 8.x continues to enforce that <cite index=”23-1″>you cannot use multipathing when combining independent hardware adapters with either software or dependent hardware adapters, and each LUN should map to only one VMFS datastore</cite>.
Historically (vSphere 6.0-era), NFS v4.1 datastores could not be combined with Storage DRS, SIOC, SRM, or vVols, and lacked VAAI hardware-acceleration support at launch<cite index=”10-1″>, meaning virtual disks created on NFS 4.1 were always thin-provisioned</cite>. Some of these limitations have narrowed over subsequent releases depending on array vendor support — verify current feature parity for NFS 4.1 against SDRS/SIOC/vVols/VAAI-NAS directly in the vSphere 8.x Storage guide for your target build, since this is one of the areas most likely to have shifted and is easy to get wrong from outdated blog posts.

4. Cost and Resource Implications

Factor	NFS	iSCSI
Storage array requirement	Any NAS/filer with an NFS export (Synology, QNAP, TrueNAS, NetApp, etc.) — often cheaper entry point	Any array or software target (TrueNAS, StarWind, dedicated SAN) presenting LUNs
Network hardware	Standard NICs; benefits from jumbo frames but not mandatory	Standard NICs (software iSCSI) or iSCSI HBAs (independent hardware, adds hardware cost but offloads CPU)
CPU overhead	Handled by NFS client stack; generally low	Software initiator adds modest host CPU load for TCP/iSCSI processing; HBA removes this entirely at a hardware cost
Licensing	No VMFS licensing implications; array-side feature licensing varies by vendor	VMFS is included in all ESXi licensing tiers; array-side feature licensing varies by vendor
Multipathing hardware	NFS v3 needs nothing extra (no true multipath); NFS v4.1 needs an array that supports session trunking	Needs multiple NICs/switches or an HBA for true redundant paths — same physical investment as most block-storage designs

For a lab or small deployment, NFS is often the lower-friction and lower-cost path because so many affordable NAS platforms expose NFS with minimal configuration. For an enterprise SAN refresh where the team already owns block-storage skills and hardware (or is migrating off Fibre Channel), iSCSI leverages existing operational investment more directly.

5. Security and Reliability

Authentication

NFS v3 effectively relies on AUTH_SYS (host/IP-based trust) there is no strong per-request authentication, which is a real limitation in zero-trust-conscious environments.
NFS v4.1 adds genuine strong authentication: ESXi supports Kerberos with two security models, and <cite index=”15-1″>a vSphere administrator specifies Active Directory credentials to provide access to NFS 4.1 Kerberos datastores, with a single set of credentials used to access all Kerberos datastores mounted on that host</cite>. Note the operational catch: <cite index=”15-1″>you cannot use two security mechanisms, AUTH_SYS and Kerberos, for the same NFS 4.1 datastore shared by multiple hosts, and all hosts sharing that datastore must use the same AD credentials</cite> — plan your AD service account strategy before rollout.
iSCSI authenticates via CHAP (one-way) or mutual CHAP (two-way), configured per initiator/target relationship mature, well-understood, and simpler to reason about than Kerberos for teams without existing AD-integrated storage.

Encryption

Neither protocol encrypts data in flight by default at the storage-protocol layer in the way that, say, NVMe/TCP with TLS or IPsec does natively out of the box for typical deployments. Kerberos krb5i provides integrity checking for NFS 4.1 traffic; genuine confidentiality/encryption in transit for either protocol typically depends on network-layer controls (IPsec, dedicated/isolated storage VLANs, or array-specific encryption features) rather than the storage protocol itself. Segment your storage network (dedicated VLAN, ideally physically isolated or air-gapped from general traffic) regardless of which protocol you choose this matters more for both protocols’ real-world security posture than the authentication mechanism alone.

RAID, Redundancy, and Data Protection

RAID and data protection are functions of the array, not the protocol this is a common point of confusion. Whether you present storage over NFS or iSCSI, the underlying RAID level, snapshot engine, replication, and dedupe/compression are determined by the storage platform underneath. The protocol choice does, however, affect how you interact with those features:

NFS commonly exposes array-native snapshots more transparently (e.g., .snapshot directory access) and lets backup tooling work at the file level.
iSCSI/VMFS snapshots go through VMware’s own snapshot mechanism at the datastore/VM level unless the array’s VAAI/VASA integration exposes array-side snapshots to vSphere directly.

Reliability Under Failure

NFS v3’s lack of native multipathing means path failure typically depends on NIC teaming/failover at the network layer rather than storage-stack awareness recovery behavior is less granular.
NFS v4.1’s session trunking actively manages path health at the protocol layer: <cite index=”14-1″>if a path goes down, it’s removed from the list of active paths until connectivity is restored</cite>.
iSCSI MPIO with Round Robin is mature and battle-tested across a huge range of array vendors, and generally considered the most operationally predictable failover behavior of the two protocols for teams used to block storage.

6. Decision Framework

Small Labs and Development Environments

Lean NFS, especially NFS v3 with a consumer/prosumer NAS (Synology, QNAP, TrueNAS). Setup is fast, VM files are transparent and easy to browse/back up, and most home-lab-grade NAS platforms have first-class NFS support with fewer gotchas than getting iSCSI CHAP and MPIO dialed in correctly on the same hardware. The performance ceiling of a 1GbE/2.5GbE lab network will rarely expose the throughput differences that matter at scale anyway.

When to reach for iSCSI instead in a lab: if you specifically want to practice enterprise block-storage skills (MPIO, CHAP, VMFS extents) because that’s what your target job/certification path requires — AZ/VMware certification labs are a legitimate reason to choose the “harder” protocol deliberately.

Mid-Market Datacenters

This is the genuine toss-up tier, and the right call depends on team skills and existing hardware more than protocol superiority:

If your team already runs iSCSI or FC SANs and has MPIO/zoning muscle memory, iSCSI minimizes new operational learning and often has better VAAI clone/move performance for VDI or dev/test provisioning workloads.
If your array vendor’s NFS implementation is mature (NetApp ONTAP is the standout example here) and your team values transparent file-level backup/DR integration, NFS v4.1 with Kerberos and multipathing is a strong, modern choice just confirm your array and ESXi build both support nconnect/session trunking before committing, since older arrays or pre-8.0U2/U3 ESXi builds won’t get the full benefit.
Jumbo frames (MTU 9000) matter for both protocols at this scale — <cite index=”28-1″>without them, a 10Gbit link can be limited to roughly 3-4Gbit of effective throughput due to frame-processing overhead</cite>, so budget the network engineering time regardless of protocol choice.

Large Enterprise Environments

At true enterprise scale, Fibre Channel or FCoE often re-enters the conversation for the highest-tier tier-0 workloads, since <cite index=”4-1″>organizations deploying vSphere in large datacenters have traditionally preferred FC/FCoE, with NFS and iSCSI positioned as the more affordable options for small and medium-size datacenters</cite>. Where NFS/iSCSI remain in play at enterprise scale:

iSCSI tends to fit environments standardizing on VMFS-based operational tooling, existing block-storage automation, and where independent hardware iSCSI HBAs are already deployed to keep host CPU overhead off software initiators.
NFS v4.1 tends to fit environments prioritizing array-native data services (dedupe, replication, snapshot-based DR) exposed transparently, and where AD-integrated Kerberos authentication aligns with existing security/compliance requirements.

When a Hybrid / Multi-Protocol Approach Makes Sense

Running both protocols side by side on the same cluster is common and often the pragmatic answer rather than a compromise:

Templates, ISOs, and content libraries on NFS (easy browsing, cheap capacity) while production VM tiers sit on iSCSI/VMFS (predictable MPIO failover, mature VAAI clone performance) — a genuinely common real-world pattern.
Different application tiers with different I/O profiles: small-file-heavy or backup-target workloads on NFS, latency-sensitive database or VDI workloads on iSCSI where clone/provisioning speed matters.
Migration periods: keeping legacy iSCSI LUNs in place while validating a newer NFS 4.1 array before a full cutover, or vice versa.

The main cost of a hybrid approach is operational: your team now needs competency in two storage stacks, two sets of monitoring/alerting, and two troubleshooting playbooks. That’s a real tax — only take it on if the workload segmentation genuinely earns it.

7. Summary Comparison Table

Dimension	NFS	iSCSI
Protocol layer	File-level	Block-level (LUN + VMFS)
Native multipathing	v3: none / v4.1: session trunking	Yes (MPIO — Round Robin, Fixed, MRU)
Strong authentication	v4.1 + Kerberos (krb5/krb5i)	CHAP / mutual CHAP
VAAI maturity	Improving, historically behind block VAAI for clone/move ops	Mature, well-established
Setup familiarity	Easier for file/NAS-oriented teams	Easier for block/SAN-oriented teams
Typical entry cost	Lower (many affordable NAS options)	Comparable, higher if using independent HBAs
Backup/DR transparency	Strong (file-level array snapshot access)	Depends on VAAI/VASA array integration
ESXi 8.x notable update	nconnect for v3 (U2) and v4.1 (U3)	CHAP/jumbo frame tuning largely unchanged, mature

Sources and Currency Notes

This guide draws on current Broadcom/VMware TechDocs for vSphere 8.0 (accessed August 2026), NetApp’s ONTAP-VMware integration documentation, and independent lab benchmarking from practitioner blogs (dated 2023–2026, cited inline). Where sources conflicted or reflected older vSphere releases (particularly NFS 4.1’s SDRS/SIOC/vVols/VAAI limitations, which originated in the 6.0 era), that’s flagged explicitly above — always cross-check against the current vSphere Storage guide for your exact build before finalizing an architecture, since NFS 4.1 feature parity has been an actively moving target across releases.

NFS vs. iSCSI for VMware ESXi: A Practitioner’s Guide to Architectural Decisions