VMware ESXi and vSphere Cluster Management

Storage Protocols for VMware ESXi

Learn how ESXi uses local, FC, FCoE, iSCSI, and NFS storage, how datastores work, and which vSphere features require shared storage.

ESXi storage fundamentals

ESXi is VMware's bare-metal hypervisor. It runs virtual machines and accesses storage through local devices or storage networks. Host storage provides the location for virtual machine files, virtual disks, ISO media, templates, logs, snapshots, swap files, and sometimes ESXi installation or boot data.

A datastore is the logical storage container that ESXi presents to administrators and virtual machines. A datastore is not the same thing as a physical disk, a LUN, a volume, an NFS export, or a storage array. It is the ESXi-visible location built on one of those underlying resources.

Local versus shared storage

Local or direct-attached storage (DAS) is physically connected to one ESXi host. Examples include internal SATA, SAS, or NVMe disks, a locally attached RAID controller, and some externally attached devices.

Shared storage is accessible by multiple ESXi hosts at the same time. It is commonly provided through a SAN using FC, FCoE, or iSCSI, or through NAS using NFS. Shared access allows hosts in a cluster to use the same virtual machine files.

Direct-attached and local storage

Local storage may consist of individual disks or disks grouped behind a host-local RAID controller. It can also include direct-attached external storage that is not presented concurrently to other ESXi hosts. ESXi may use suitable local block devices to create VMFS datastores.

Common uses

• ESXi boot or installation media, depending on the deployment design.
• Single-host labs and training environments.
• Small standalone deployments and branch offices.
• ISO repositories and template storage.
• Archived or retired virtual machines.
• Noncritical workloads where host-level availability is acceptable.
• Local scratch or temporary storage where appropriate.

Limitations

• Storage is ordinarily visible to only the host to which it is attached.
• A host failure can make the files inaccessible even if the disks themselves are healthy.
• Traditional cross-host vMotion cannot use a VM datastore that only one host can access.
• HA cannot restart a VM on another host if that host cannot access the VM's files.
• DRS cannot freely place or migrate workloads across hosts when their storage is host-specific.
• Maintenance and hardware replacement require extra planning, such as copying or migrating the workload's storage.

Local storage is therefore practical when simplicity and low cost matter more than multi-host mobility or clustered availability.

Shared storage

Shared storage is storage that multiple ESXi hosts can access concurrently. A shared datastore gives each participating host a consistent view of virtual machine files and available capacity.

Shared storage supports centralized VM placement, capacity pooling, cluster operations, maintenance flexibility, and workload movement. A cluster can use storage allocations that are larger than the capacity physically installed in any one host, provided the storage system and connectivity are designed to deliver that capacity.

Shared storage does not automatically mean high availability. Availability depends on redundant storage controllers, network or SAN paths, switches, permissions, zoning or masking, multipathing, storage performance, and tested failover procedures.

Shared-storage design elements

• Storage target: The array or NAS system providing capacity.
• Host connectivity: HBAs, NICs, VMkernel adapters, switches, fabrics, and cabling.
• Access control: LUN masking, FC zoning, iSCSI access controls, or NFS export permissions.
• Redundancy: Multiple adapters, paths, switches or fabrics, and storage controllers.
• Performance: Sufficient IOPS, throughput, latency, cache, and network capacity.
• Compatibility: Supported ESXi release, firmware, driver, array, and protocol combinations.

Storage protocols supported by ESXi

ESXi uses two broad access models: block storage and file storage. FC, FCoE, and iSCSI normally present block devices. NFS presents a remote file system. Local disks and RAID-backed devices are also block storage from ESXi's perspective.

Fibre Channel and SAN

Fibre Channel (FC) is a storage networking protocol usually deployed through dedicated SAN fabrics. An ESXi host uses one or more FC host bus adapters (HBAs) to reach storage-array ports. The array presents one or more LUNs, which are logical block-storage units. ESXi can format suitable LUNs as VMFS datastores.

Enterprise FC designs commonly use two independent fabrics, redundant HBAs or ports, and redundant storage controllers. Zoning and LUN masking determine which hosts can see which storage.

Fibre Channel over Ethernet

FCoE carries Fibre Channel traffic over Ethernet infrastructure. It can reduce separate cabling by converging storage and other traffic, but it still requires lossless or otherwise appropriately engineered Ethernet, compatible converged adapters, switches, firmware, drivers, arrays, and ESXi support. Use the applicable VMware and vendor compatibility documentation before selecting FCoE.

iSCSI

iSCSI transports SCSI block commands over IP. ESXi can use several conceptual adapter types:

• Software iSCSI adapter: An ESXi initiator implemented in software and using standard network adapters.
• Dependent hardware iSCSI adapter: Hardware-assisted iSCSI functionality that relies partly on ESXi networking and a compatible network adapter.
• Independent hardware iSCSI adapter: A dedicated adapter that handles iSCSI processing and connectivity more independently.

In a typical software iSCSI design, an administrator creates a dedicated VMkernel port, assigns it an IP address and storage VLAN, configures a target using dynamic discovery or a static address, and then rescans the adapter. CHAP may be configured when required by the storage security design.

NFS

NFS is a network file-sharing protocol. An ESXi host mounts an export from an NFS server or NAS appliance as an NFS datastore rather than formatting a LUN as VMFS. The supported NFS versions and feature behavior depend on the applicable vSphere release. Common vSphere releases support NFS 3 and NFS 4.1 with different configuration and capability considerations, so verify the exact release and vendor interoperability guidance.

Block versus file storage

With FC, FCoE, iSCSI, or a local disk, ESXi sees a block device. When appropriate, ESXi formats that device with VMFS, VMware's file system for VMFS datastores. The array may call the device a LUN or volume, but ESXi presents the formatted result as a datastore.

With NFS, the storage system exposes a file share called an export. ESXi mounts that export directly as an NFS datastore. There is no VMFS formatting step on the ESXi host.

Datastores and their contents

A datastore is the logical location ESXi uses for virtual machine and related files. Typical contents include virtual disks, configuration files, snapshot files, VM swap files, templates, ISO files, and logs when configured to reside there.

• VMFS datastore: Created on or mounted from a block device such as a LUN.
• NFS datastore: Mounted from an NFS server export.

Multiple hosts can mount the same shared datastore when storage access, permissions, protocol versions, hardware, and vSphere compatibility requirements are satisfied. Do not confuse a datastore with the underlying disk, LUN, volume, export, or array: several storage layers exist between the physical media and a VM's files.

Shared storage and vSphere features

Shared storage is the traditional foundation for multi-host vSphere clusters. Every host that may run a VM must be able to access the VM's datastore and required files.

vMotion

vMotion is the live migration of a running VM between ESXi hosts. In the traditional shared-storage workflow, both hosts access the same datastore, so the VM's files remain in place while execution moves to the destination host. Shared storage simplifies this process and is essential to the classic model.

Modern workflows can migrate storage as part of a move or use alternative architectures, but those workflows do not remove the need to understand datastore accessibility and application requirements.

vSphere HA

vSphere High Availability (HA) restarts eligible VMs on surviving hosts after an ESXi host failure. The surviving host must be able to reach the VM's configuration, virtual disks, and other required files. Shared storage therefore enables restart access, but HA also requires correctly configured cluster networking, admission control, compatibility, and licensing or feature prerequisites.

DRS

Distributed Resource Scheduler (DRS) balances workloads across cluster hosts and can recommend or automate placement and migration. Storage accessibility limits where a VM can run. A shared datastore gives DRS more freedom to place workloads across hosts, while host-local datastores constrain placement.

Availability and multipathing

Multipathing uses multiple paths between an ESXi host and a shared block-storage target. Paths may traverse separate adapters, cables, switches or SAN fabrics, and storage controllers. If one path fails, another can continue carrying storage traffic.

ESXi uses a path selection policy to choose among available paths. Policy names and supported behavior vary by storage type and release. Follow the array vendor's recommendation rather than selecting a policy solely because it sounds more balanced.

NFS resiliency is designed differently. It depends on redundant network adapters and switches where appropriate, reliable routing and VLANs, redundant NAS interfaces or controllers, and a storage platform that supports the required failover behavior. Validate the failure behavior instead of assuming that multiple network links automatically provide seamless NFS failover.

Protocol selection considerations

• Performance: Compare latency, IOPS, throughput, queue depth, and workload patterns. A fast protocol cannot compensate for an overloaded array or undersized network.
• Infrastructure: FC requires SAN HBAs, fabrics, switches, and cabling. iSCSI and NFS use Ethernet NICs, switches, VMkernel networking, and IP storage targets.
• Cost: Consider adapters, switches, optics, cabling, array features, support contracts, and administrator training.
• Operational complexity: FC introduces fabric zoning and SAN management. iSCSI introduces initiators, targets, VLANs, discovery, and possibly CHAP. NFS introduces exports, permissions, routing, and NAS administration.
• Scalability: Plan for additional hosts, datastores, ports, paths, controllers, and aggregate bandwidth.
• Existing skills: An organization with an established SAN may prefer FC, while an IP-oriented team may prefer iSCSI or NFS.
• Redundancy: Avoid one NIC, one HBA, one switch, one fabric, one storage controller, or one cable as the only route to production data.
• Security: Isolate storage traffic with dedicated networks or VLANs, restrict target and export access, use NFS permissions appropriately, and use CHAP for iSCSI when required.

Planning a storage design

1. List VM capacity, expected growth, performance requirements, snapshot usage, template libraries, ISO repositories, and backup staging needs.
2. Reserve operational headroom for VM growth, snapshots, temporary files, maintenance, and storage-system overhead. Do not plan to run a datastore permanently at full capacity.
3. Choose local storage when workloads are simple, isolated, or noncritical and host-specific access is acceptable.
4. Choose FC or FCoE when a supported enterprise SAN fabric already exists and the organization can operate it.
5. Choose iSCSI when shared block storage over an IP network fits the skills and infrastructure available.
6. Choose NFS when NAS-based file storage and straightforward datastore presentation are preferred.
7. Design redundant paths and test a planned failure before placing critical workloads into production.

Configuration examples

Discovering adapters and rescanning storage

Use the ESXi Host Client or vSphere Client to inspect storage adapters, VMkernel storage networking, discovered devices, datastores, and paths. After presenting a new LUN, iSCSI target, or path, rescan the relevant storage adapters.

esxcli storage core adapter list
esxcli storage core adapter rescan --all
esxcli storage core device list
esxcli storage core path list

CLI syntax and available subcommands can vary by ESXi release. Confirm the commands against the installed version. A rescan cannot fix missing zoning, masking, VLAN connectivity, target access, or physical links.

Software iSCSI workflow

1. Enable or add the software iSCSI adapter in the ESXi Host Client or vSphere Client.
2. Create or select a dedicated VMkernel port for storage traffic.
3. Assign the storage VLAN and IP configuration, using the network design recommended for the environment.
4. Add a dynamic discovery target or a static target address.
5. Configure CHAP only when required by the storage design, using matching settings on the target.
6. Rescan the adapter and verify the discovered devices and paths.
7. Present the device consistently to every intended ESXi host before creating or mounting a shared VMFS datastore.

NFS datastore workflow

1. Identify the NFS server address, exact export path, desired datastore name, and supported NFS version.
2. Verify VMkernel network reachability from each intended host to the NFS server.
3. Confirm that server-side export permissions allow the hosts or their storage subnet.
4. Mount the export through the ESXi Host Client or vSphere Client.
5. Verify datastore visibility and consistent access on all intended hosts.

VMFS datastore workflow

1. Present a correctly sized LUN to every intended host.
2. Verify the device identity, capacity, host access, and path health.
3. Confirm that the device is new or otherwise safe to use.
4. Create a VMFS datastore or mount an existing VMFS datastore.
5. Never format a LUN that contains required existing data.

Path and resilience verification

• Review visible paths and their states for each shared block device.
• Confirm that the active and standby paths match the storage vendor's design.
• Use the vendor-recommended path selection policy.
• Test a planned adapter, link, switch, fabric, or controller failure during an approved maintenance window.
• Verify that workloads remain accessible and that alerts identify the failed component.

Troubleshooting storage problems

A newly presented SAN LUN does not appear

Possible causes include missing FC zoning or LUN masking, an incorrect iSCSI initiator identity, an unconfigured target, a missing rescan, or a failed physical path, VLAN, switch, HBA, or target connection.

• Confirm adapter status and initiator identifiers on the ESXi host.
• Verify array presentation, FC zoning, or iSCSI target access.
• Rescan storage adapters.
• Inspect detected devices and paths, then compare the result with a working host.

An NFS datastore mount fails

Check the server address, exact export path, export permissions, routing, VLANs, firewall rules, DNS where used, and the selected NFS version. Test VMkernel reachability to the NFS server and validate the server-side export configuration.

vMotion or HA is unavailable for locally stored VMs

The VM files may reside only on one host's local datastore. Confirm datastore visibility from every participating host. Where traditional shared-storage behavior is required, move the workload to a shared datastore and review cluster networking, VMkernel configuration, licensing, and other feature prerequisites.

A shared datastore is visible to only one host

• Compare storage adapters, initiator identities, VLANs, VMkernel settings, and target access across hosts.
• Check consistent LUN presentation, zoning, masking, or NFS export permissions.
• Rescan the affected host.
• Mount the existing datastore on the remaining hosts; do not reformat the shared device.

Storage performance is poor or intermittent

• Review datastore latency, throughput, queueing, and path health.
• Check for failed or missing paths and confirm expected path-selection behavior.
• Inspect switch, NIC, HBA, cable, and storage-array metrics.
• Look for oversubscribed array resources or storage-network congestion.
• Confirm that storage traffic is appropriately separated and sized.

Practical scenarios

Single-host lab or branch office

Install ESXi on suitable local boot media and store low-priority VMs, ISO files, and templates on locally attached RAID storage. This is practical when there is no requirement for cross-host mobility or clustered availability.

Two or more hosts requiring maintenance flexibility

Present the same iSCSI LUNs to every host, create shared VMFS datastores, and place production VMs on those datastores. Each host can then access the VM files for traditional vMotion and cluster operations.

NAS-based deployment

Export a dedicated NFS share from a NAS appliance and mount it as an NFS datastore on each ESXi host. This provides shared datastore access without presenting and formatting SAN LUNs as VMFS.

Existing Fibre Channel fabric

Use redundant FC HBAs, separate SAN fabrics, and array-presented LUNs configured according to the storage vendor's compatibility guidance. This fits organizations with established SAN infrastructure and operational expertise.

Host failure in a cluster

If a host fails while its VM files remain available on shared storage, vSphere HA can restart eligible VMs on surviving hosts. The result depends on surviving-host access, cluster configuration, capacity, and the health of the shared storage system.

Key points to remember

• ESXi consumes local or networked storage through datastores.
• Local storage is simple but normally host-specific.
• FC, FCoE, and iSCSI usually provide block devices that ESXi can format as VMFS.
• NFS provides a file-based datastore by mounting an export.
• Shared storage enables the traditional multi-host model for vMotion, HA restart access, and DRS mobility.
• Redundant paths, correct permissions and presentation, compatible hardware, and tested failover are as important as protocol choice.
• Always verify support against the exact ESXi/vSphere release, certified hardware, storage array, drivers, firmware, and vendor documentation.

Continue with Storage Protocols for VMware ESXi as a reference while planning datastore and cluster storage.