5.2 NFS Datastores, Software iSCSI & Multipathing (NMP)

5.2 NFS Datastores, Software iSCSI & Multipathing (NMP)

While Fibre Channel provides dedicated, high-speed block storage fabrics, many enterprise environments leverage Ethernet infrastructure to deliver file-level Network Attached Storage (NAS) via NFS or block-level storage via iSCSI. To ensure high availability, load balancing, and fault tolerance across diverse storage fabrics, ESXi incorporates the Pluggable Storage Architecture (PSA) and the Native Multipathing Plugin (NMP). Understanding the configuration nuances and architectural constraints of these storage protocols is critical for real-world operations and certification success.

---

Network Attached Storage (NAS) & NFS Datastores

Unlike block storage (FC, iSCSI), where the ESXi hypervisor owns the file system (VMFS) and manages block layout, Network Attached Storage (NAS) utilizes a remote file server that manages its own underlying file system. The ESXi host accesses this storage over the standard TCP/IP network using the Network File System (NFS) protocol.

Virtual machine files (.vmdk, .vmx, .vswp) reside directly on the remote NFS share as native files. The VMkernel implements a specialized NFS client that issues standard POSIX-like file access calls across dedicated VMkernel network adapters.

1. NFS v3 vs. NFS v4.1 Architectural Comparison

vSphere supports two major versions of the NFS protocol, each exhibiting fundamentally different operational and security models:

Protocol State & File Locking

• NFS v3: A stateless protocol. Because NFS v3 lacks built-in stateful locking mechanisms suitable for multi-hypervisor virtualization clusters, VMware implemented a proprietary client-side locking mechanism. When an ESXi host powers on a VM on an NFS v3 volume, it generates a hidden lock file (e.g., .lck-<filename>) on the remote share to claim exclusive write access. If a host crashes, stale lock files can persist on the NAS, preventing other hosts from restarting the VM until the lock times out or is manually cleared.
• NFS v4.1: A fully stateful protocol. NFS v4.1 features built-in server-side open/close state tracking, share reservations, and lease renewal mechanisms. The NAS server arbitrates locks directly, eliminating hidden client .lck files and drastically improving failover recovery speeds during host outages.

Connections and Multipathing

NFS v3 and NFS v4.1 have different locking and session models. Modern ESX also supports nConnect for multiple TCP connections on supported NFS configurations; do not memorize the old rule that every NFS v3 datastore always has exactly one TCP connection. NFS v4.1 session trunking is a distinct capability requiring a supported server and correct endpoint configuration.

A higher connection count is not automatically independent path redundancy. Inspect VMkernel routing, physical uplinks and server endpoints. Validate the configuration against the NAS vendor's support guidance and the host release.

Security & Authentication

• NFS v3: Relies on legacy AUTH_SYS (UNIX style authentication). User identifiers (UID) and group identifiers (GID) are transmitted across the network in cleartext without cryptographic verification. Storage access control is typically restricted solely via IP address whitelisting on the NAS export.
• NFS v4.1: Provides enterprise-grade authentication via Kerberos integrated with Microsoft Active Directory or an enterprise KDC:
  • krb5: Cryptographic user authentication.
  • krb5i: Kerberos authentication plus data integrity protection (cryptographic checksums appended to every RPC packet to prevent man-in-the-middle tampering).
  • krb5p: Kerberos authentication plus complete data privacy (payload encryption of all NFS traffic traversing the wire).

Cluster Interoperability Rule

An NFS share cannot be mounted as both NFS v3 and NFS v4.1 simultaneously across different hosts in the same cluster. All ESXi hosts accessing a specific export must utilize the exact same protocol version to prevent unsupported mixed-locking behavior.

---

NFS Protocol Comparison Matrix

---

Software iSCSI Architecture & Configuration

iSCSI (Internet Small Computer System Interface) transports standard SCSI block commands over standard IP networks using TCP/IP (port 3260). Through iSCSI, ESXi treats Ethernet network adapters as virtual SCSI controllers, presenting remote storage as standard block-level SCSI disks.

1. The Software iSCSI Adapter (vmhbaXX)

ESXi includes a built-in Software iSCSI Initiator. Rather than requiring expensive, specialized hardware iSCSI HBAs, the hypervisor's VMkernel handles SCSI-to-IP encapsulation entirely in software via host CPU processing. Once enabled in vCenter Server, the Software iSCSI adapter is assigned a virtual adapter name (such as vmhba64).

2. iSCSI Addressing & Identifiers

iSCSI nodes (both initiators and targets) are uniquely identified by an iSCSI Qualified Name (IQN). The IQN adheres to a standardized format: iqn.yyyy-mm.naming-authority:unique-name (for example, iqn.1998-01.com.vmware:esx01-7b8f9a2c). Alternatively, an Extended Unique Identifier (EUI) can be used (e.g., eui.0123456789abcdef).

3. Target Discovery Mechanisms

Before an ESXi host can format a LUN with VMFS, it must discover the storage array's target portals:

• Dynamic Discovery (SendTargets): The administrator inputs the IP address (or DNS name) and TCP port (default 3260) of the storage array target controller. The ESXi host initiates a TCP session and queries the array. The array responds with a complete list of all accessible target IQNs and available portal IP addresses. This is the standard enterprise discovery method.
• Static Discovery: The administrator manually enters the exact target IQN, target IP address, and port. Static discovery is utilized when firewall policies restrict dynamic SendTargets queries, or when an administrator intentionally limits discovery to a specific target.

4. iSCSI Authentication: Unidirectional vs. Mutual CHAP

iSCSI utilizes Challenge Handshake Authentication Protocol (CHAP) to authenticate communicating entities:

• Unidirectional (Target) CHAP: The storage target authenticates the ESXi host (initiator). The host presents a shared secret username and password to gain access to the LUNs.
• Mutual (Bidirectional) CHAP: A two-way authentication handshake. The target authenticates the ESXi host, and simultaneously, the ESXi host authenticates the storage target using a second unique secret. Mutual CHAP prevents "rogue storage spoofing" and man-in-the-middle attacks on the enterprise IP storage network.

5. iSCSI Port Binding Architecture & Constraints

To achieve network redundancy and multi-pathing over Software iSCSI, administrators bind multiple VMkernel network adapters (vmknics) directly to the Software iSCSI adapter. However, this configuration is governed by strict architectural rules:

• When to Use Port Binding: Use port binding when all host vmknics and array target portals are on a single, flat IP subnet. Each bound vmknic must be configured on a port group with exactly one active physical uplink and no standby uplinks (1:1 mapping).
• When NOT to Use Port Binding (Routed Storage): If the storage array presents target portals across different routed IP subnets (e.g., Portal 1 on 192.168.10.0/24 and Portal 2 on 192.168.20.0/24), port binding must NOT be configured. Attempting to bind VMkernel ports across routed subnets overrides the hypervisor's standard IP routing table, causing packets to be routed out the wrong physical interface. This results in severe route flapping, intermittent dropped connections, and storage All Paths Down (APD) conditions. In routed storage topologies, administrators rely on standard IP routing and multiple VMkernel adapters without port binding.

---

Pluggable Storage Architecture (PSA) & Native Multipathing (NMP)

To manage storage multi-pathing, ESXi employs a modular kernel framework known as the Pluggable Storage Architecture (PSA). The PSA provides open APIs that allow third-party hardware vendors to inject proprietary Multipathing Plugins (such as Dell PowerPath), while delivering a robust default engine: the Native Multipathing Plugin (NMP).

The Native Multipathing Plugin coordinates two specialized sub-plugins for every presented storage LUN:

1. Storage Array Type Plugins (SATP)

SATPs are hardware-specific plugins responsible for array lifecycle management:

• Monitors the health and physical connectivity of every path.
• Detects path failures and initiates storage controller failover sequences.
• Executes array-specific commands (such as activating a passive storage processor).
• Common SATPs include:
  • VMW_SATP_ALUA: For modern Asymmetric Logical Unit Access arrays. Monitors Active/Optimized versus Active/Unoptimized path states.
  • VMW_SATP_DEFAULT_AA: For symmetrical Active-Active arrays where all paths deliver identical performance.
  • VMW_SATP_DEFAULT_AP: For legacy Active-Passive arrays where one controller owns the LUN and the standby controller drops I/O.

2. Path Selection Plugins (PSP)

While the SATP monitors path health, the Path Selection Plugin (PSP) chooses which physical path will transmit each outgoing I/O request. vSphere provides three standard PSP policies:

Path Selection Policies

Fixed prefers a configured path and can return to it after recovery. Most Recently Used (MRU) continues using the selected working path after failover. Round Robin (RR) distributes I/O over eligible paths, respecting the device's path states and the supported array configuration. An active/unoptimized path is not equivalent to a failed path, but may involve a less direct controller route.

Use the vendor-recommended policy and switching parameters. Changing RR to one I/O per path can be appropriate for specified arrays; it is not a universal optimization and cannot guarantee throughput or prevent all queueing. Inspect current path health before tuning. Modern NVMe devices may use HPP rather than NMP, so an NMP command does not configure every storage device.

For a path-failure exercise, record healthy path count, unplug only the designated redundant lab link, observe failover and workload I/O, restore the link, and verify the intended failback behavior. Do not infer redundancy from the number of physical cables alone: two paths through one failed controller or one switch can still share a failure domain.

Official Reading

Use the official 2V0-16.25 objective guide for scope and Broadcom technical documentation for the installed 9.0 component. This independent lesson was reviewed October 18, 2026; actual deployment support depends on the applicable version and configuration.

Source Notes

NFS client capability reference records KRB5P capability beginning with 9.0; NFS support guidance covers modern connection options. Checked October 18, 2026.

Review Takeaways

• NFS v3 and v4.1 differ in locking and security; modern ESX also offers supported nConnect configurations, so old single-connection rules are insufficient.
• An NFS export cannot be concurrently mounted using both NFS v3 and NFS v4.1 within the same vSphere cluster due to fundamentally incompatible locking engines.
• The ESXi Software iSCSI adapter encapsulates SCSI CDBs into TCP/IP frames using IQN identifiers, supporting SendTargets dynamic discovery and bidirectional (mutual) CHAP authentication.
• iSCSI port binding requires all bound VMkernel adapters and storage target portals to reside on the same broadcast domain and IP subnet; binding across routed subnets causes route flapping and storage All Paths Down (APD) conditions.
• NMP combines array-specific failover handling with path selection; choose RR and its parameters according to the validated storage-vendor configuration.

The official ESX host-capability API marks NFSv4.1 krb5p support as a 9.0 capability; older ESXi NFS summaries may describe different security support.