VMware ESXi and vSphere Cluster Management
Storage Protocols for VMware ESXi
Learn how ESXi uses local storage, Fibre Channel, FCoE, iSCSI, and NFS, and how storage choices affect datastores, vMotion, HA, DRS, and resiliency.
VMware ESXi can store virtual machines on disks inside a host or on storage supplied by a SAN or NAS. The storage protocol determines how ESXi reaches that storage; the datastore type determines how ESXi organizes files for virtual machines.
This lesson explains local and shared storage, block and file protocols, datastores, multipathing, selection criteria, and the effect of storage design on vSphere cluster features.
ESXi storage overview
ESXi is VMware's bare-metal hypervisor. It uses storage for its installation, virtual machine configuration files, virtual disks, snapshots, templates, ISO images, logs, and other files.
The main storage distinction is between local or direct-attached storage and shared storage:
- Local storage is attached to an individual ESXi host. Other hosts cannot automatically access it.
- Shared storage is accessible by multiple ESXi hosts at the same time, subject to correct presentation, permissions, networking, and compatibility.
ESXi normally reaches storage through a chain of components:
- A storage adapter, such as an HBA, or a network adapter carries the connection.
- One or more paths connect the host to a storage device, target, or file server.
- Block storage presents a LUN, which is a logical block-storage unit. File storage presents an export, such as an NFS export.
- ESXi formats a block device with VMFS or mounts an NFS export.
- The result is a datastore, the logical container used for virtual machine and related files.
The protocol and the datastore format are different concepts. FC, FCoE, and iSCSI transport block storage to ESXi; ESXi commonly creates a VMFS datastore on that block device. NFS transports files from a NAS system; ESXi mounts the export directly as an NFS datastore instead of formatting a LUN with VMFS.
Direct-attached and local storage
Direct-attached storage (DAS) is storage physically connected to one host rather than presented through a shared storage network. Examples include internal disks, disks behind a RAID controller, and directly attached storage devices.
Local storage is often suitable for:
- ESXi boot or installation media
- A single-host lab or small standalone environment
- ISO image repositories and templates
- Temporary content or test virtual machines
- Noncritical or archived virtual machines
A local VMFS datastore can be useful when simplicity and low cost matter more than cluster mobility. However, a datastore on one host is not inherently visible to another host. This restricts host-to-host mobility and cluster-oriented functions that require the same virtual machine files to be available on multiple hosts.
Plan local storage carefully:
- Availability: RAID can protect against some disk failures, but it does not make the datastore available after the entire host fails.
- Capacity: Account for virtual disks, snapshots, templates, ISO files, logs, and free space required for operations.
- Backup: Back up virtual machines and important files independently of the host. A second copy on another local disk is not automatically a complete backup strategy.
- Hardware failure: A failed controller, backplane, motherboard, or host can make local workloads unavailable until the hardware is repaired or the workloads are restored elsewhere.
Shared storage
Shared storage is storage that more than one ESXi host can access concurrently. It commonly provides a central location for virtual machine files, templates, ISO images, and larger storage allocations.
Shared storage is a foundation for many multi-host designs. When every intended host can access the datastore containing a virtual machine, vSphere can place or move that virtual machine among hosts, subject to other requirements.
- vMotion: A running virtual machine can generally move between compatible hosts without downtime when both hosts can access the required files and the other vMotion requirements are satisfied.
- vSphere High Availability (HA): After a host failure, HA can restart affected virtual machines on surviving hosts when those hosts can access the virtual machine files.
- Distributed Resource Scheduler (DRS): DRS balances workload placement and may recommend or automate migrations. Consistent shared-datastore access is important when workloads move between hosts.
- Multi-host virtual machine clustering: Some guest clustering designs require shared storage or carefully designed storage access between hosts. Follow the compatibility requirements of the guest and vSphere release.
Shared storage does not eliminate the need for redundancy. The array, storage controllers, fabrics or switches, adapters, cables, network paths, and power systems can all affect availability.
For related cluster preparation, see Create Clusters, Enhanced vMotion Explained, Enable vSphere HA, and Enable DRS.
Block storage protocols
Fibre Channel
Fibre Channel (FC) is a dedicated storage-area-network protocol for block storage. An ESXi host uses a Fibre Channel host bus adapter (HBA) to connect through one or more FC fabrics to a storage array. The array presents LUNs, and ESXi discovers those LUNs as block devices.
FC commonly provides predictable performance and separate storage fabrics, but it requires FC-capable HBAs, switches, cabling, zoning, array configuration, and administrators familiar with SAN operations. See Fibre Channel Overview and FC Components.
Fibre Channel over Ethernet
Fibre Channel over Ethernet (FCoE) carries Fibre Channel frames over a suitable Ethernet infrastructure. It still provides block storage and LUNs, but the Ethernet network must support the required lossless behavior and traffic-management features.
FCoE requires compatible converged network adapters or adapters, switches, firmware, drivers, and a design that meets the storage vendor's requirements. It is not the same as sending ordinary FC traffic through an arbitrary Ethernet network. See FCoE Adapters Explained.
iSCSI
iSCSI carries SCSI commands over IP networks. An ESXi host uses an iSCSI initiator to create sessions with an iSCSI target. The target is the storage-system endpoint that offers one or more LUNs.
Conceptually, iSCSI implementations fall into three groups:
- Hardware iSCSI adapter: A dedicated adapter handles iSCSI processing and presents storage to ESXi.
- Software iSCSI adapter: ESXi uses a software initiator and suitable network adapters to send iSCSI traffic.
- Dependent hardware iSCSI: A network adapter provides hardware assistance while relying on ESXi networking and storage components for part of the operation.
iSCSI designs require target discovery, initiator and target access configuration, network reachability, and often dedicated VMkernel networking. Authentication such as CHAP may be used where supported. Learn more in iSCSI Initiators, iSCSI Target Discovery, and Configure iSCSI CHAP.
LUN discovery, paths, and multipathing
For block storage, the storage system presents LUNs to hosts through targets, fabrics, or network sessions. ESXi discovers the devices during adapter scans. A path is one route between the host and a storage device.
Multipathing uses multiple independent paths to shared block storage. Multiple HBAs or network interfaces, separate switches or fabrics, and redundant storage controllers can allow storage access to continue after a component or link fails. Depending on the supported configuration, multipathing can also distribute I/O.
A path selection policy determines how ESXi selects among available paths. If one path fails, ESXi can use another path when the design and policy support failover. A configuration with several cables connected to the same failed switch is not fully independent redundancy.
NFS file storage
Network File System (NFS) is a file-sharing protocol commonly provided by a network-attached storage (NAS) system. The NAS exports a directory, and each ESXi host mounts that export as a datastore.
Unlike block storage, ESXi does not format an NFS export with VMFS. The NAS manages the file system, while ESXi uses the mounted NFS datastore for virtual machine files, templates, ISO images, and related content.
NFS requires:
- IP reachability from an appropriate ESXi VMkernel interface to the NAS
- Correct NAS server address and export path
- Export permissions that authorize every intended ESXi host
- Compatible NFS version support on both the installed ESXi release and the storage array
- Suitable network capacity, redundancy, and traffic isolation for the workload
NFS version behavior and feature support vary by ESXi/vSphere release and storage vendor. Verify the supported combination before deployment. For configuration guidance, see Configure NFS Datastore.
Datastores
A datastore is the logical storage container ESXi uses for virtual machine configuration files, virtual disks, snapshots, templates, ISO files, logs, and other host-visible files.
- VMFS datastore: Usually created on a block device such as an FC, FCoE, or iSCSI LUN. VMFS is VMware's file system for organizing files on that device.
- NFS datastore: Created by mounting an NFS export from a NAS system. The NAS provides the underlying file system.
Several physical paths may lead to one block device, and several devices may contribute to a datastore design. ESXi abstracts these details so administrators work with a datastore name and its capacity while the storage stack manages device and path access.
Use clear, consistent datastore names. Monitor total capacity, provisioned capacity, actual free space, snapshot growth, template usage, and log placement. In a cluster, verify that every host requiring a datastore sees it with consistent access and compatible permissions.
See Create VMFS Datastore and Browse VMFS Datastores for related administration tasks.
Storage protocol comparison
| Storage type or protocol | Block or file access | Typical transport | Shared across ESXi hosts | Typical datastore type | Common use case | Key infrastructure requirements |
|---|---|---|---|---|---|---|
| Local/direct-attached storage | Local block devices | Internal buses, RAID controllers, or direct attachment | No, not inherently | VMFS or local device use | Single-host labs, boot media, templates, temporary or noncritical workloads | Host disks, controller support, capacity, RAID, and backup |
| Fibre Channel | Block | Dedicated FC SAN fabric | Yes | VMFS | Enterprise shared storage and predictable SAN performance | FC HBAs, fabrics, zoning, array presentation, and multipathing |
| Fibre Channel over Ethernet | Block | Suitable lossless Ethernet | Yes | VMFS | Converged network and storage environments | FCoE-capable adapters, switches, firmware, traffic controls, and SAN design |
| iSCSI | Block | IP/Ethernet network | Yes | VMFS | Ethernet-based SANs and cost-conscious shared storage | Initiators, targets, VMkernel networking, discovery, authentication, and multipathing |
| NFS | File | IP/Ethernet network | Yes | NFS datastore | NAS-first environments and simple shared file storage | NAS exports, permissions, VMkernel reachability, version compatibility, and network design |
How to select a storage protocol
| Environment condition | Suitable option | Reason | Design caution |
|---|---|---|---|
| Small single-host deployment | Local storage | Simple and economical without shared-storage infrastructure | No inherent multi-host mobility or host-failure failover |
| Existing Fibre Channel SAN | FC | Uses established dedicated SAN skills and infrastructure | Plan zoning, LUN masking, redundant fabrics, and HBA compatibility |
| Ethernet-based block SAN | iSCSI | Uses IP networking and may reduce the need for a separate FC fabric | Design isolated, redundant storage networking and validate latency and congestion behavior |
| NAS-first environment | NFS | Provides shared file storage without creating VMFS on a LUN | Export permissions, NFS support, network availability, and NAS performance are critical |
| High-availability multi-host cluster | Redundant shared FC, FCoE, iSCSI, or NFS | Lets hosts access common VM files for migration and restart workflows | All hosts need consistent visibility, plus resilient storage and cluster networking |
Choose based on environment size, budget, existing SAN or Ethernet expertise, network design, performance and latency requirements, operational simplicity, and availability goals. A technically fast protocol is not automatically the best choice if the team cannot operate it reliably.
Storage type and vSphere capability considerations
| Capability | Local storage on one host | Shared FC/FCoE/iSCSI storage | Shared NFS storage | Important caveat |
|---|---|---|---|---|
| Centralized virtual machine file storage | Limited to the host | Yes, through VMFS datastores | Yes, through NFS datastores | Capacity, permissions, and storage availability still apply |
| Multi-host datastore access | Normally no | Yes | Yes | Every host must be correctly presented or authorized |
| vMotion | Generally unavailable for files that only one host can access | Generally supported when other requirements are met | Generally supported when other requirements are met | Compatibility, networking, CPU, licensing, and VM configuration also matter |
| vSphere HA restart access | Another host cannot use the local files automatically | Surviving hosts can access shared files | Surviving hosts can access shared files | HA also requires correct cluster configuration and admission design |
| DRS workload placement and migration | Placement is constrained by local file access | Shared access supports movement among hosts | Shared access supports movement among hosts | DRS depends on cluster, compatibility, networking, and resource conditions |
| Virtual machine clustering across hosts | Usually unsuitable for shared-disk requirements | May support applicable designs | May support applicable designs | Follow guest, vSphere, and storage-vendor requirements for the specific cluster |
vMotion generally requires both source and destination hosts to access the same virtual machine files on shared storage. Alternative migration methods exist in some designs, but they do not remove the need to evaluate downtime, data transfer, compatibility, and capacity.
Connectivity and resiliency fundamentals
- Use multiple storage paths, such as multiple HBAs or network adapters.
- Use separate switches or fabrics where practical so one component failure does not remove every path.
- Use dedicated or properly isolated storage networks and VMkernel interfaces.
- Configure and review multipathing for shared block storage.
- Monitor path states, adapter health, switch errors, storage-controller events, latency, and datastore capacity.
Redundancy must be end to end. Two host ports connected to one failed switch do not provide the same protection as ports connected to independent switches. Likewise, redundant host paths cannot compensate for a single storage controller or array component that is not designed for failure.
Basic storage security
- Segregate storage traffic from general management and user traffic with appropriate physical or logical network controls.
- Restrict iSCSI targets and LUN access to authorized initiators and hosts.
- Use authentication, such as CHAP, where supported and required by policy.
- Restrict NFS exports to the intended ESXi hosts and networks.
- Apply least privilege to storage administration and datastore access.
- Protect storage-management interfaces and review logs for unexpected access or path changes.
Configuration workflow
- Verify that adapters, HBAs, NICs, switch ports, firmware, drivers, and storage-array versions are supported for the installed ESXi release.
- For FC or FCoE, configure adapters and fabric connectivity, zone and map LUNs to every intended host, rescan storage, and create or mount the VMFS datastore.
- For iSCSI, enable the appropriate adapter, create dedicated VMkernel networking as required, add target-discovery information, configure authentication if used, rescan adapters, and create or mount VMFS datastores.
- For NFS, configure VMkernel connectivity, authorize all intended hosts in the NAS export, add the server and exact export path, select a supported NFS version, and mount the datastore.
- For shared block storage, configure independent paths and review the selected multipathing policy.
- Confirm that all cluster hosts can see the required datastores with consistent access before placing production workloads on them.
Troubleshooting storage connectivity
Datastore visible on one host but not another
- Likely causes: The LUN was not presented, zoned, or mapped to every host; an iSCSI target is missing or unreachable; NFS export permissions omit the affected host; or the host has not rescanned its adapters.
- Checks: Compare adapter visibility, paths, target sessions, and datastore lists. Verify zoning, LUN masking, VLAN and routing configuration, NFS export access, and then rescan storage after correcting the issue.
vMotion or HA cannot use another host
- Likely causes: The destination host cannot access the VM datastore, shared-storage visibility is inconsistent, or cluster networking and compatibility requirements are incomplete.
- Checks: Confirm that the datastore is mounted and accessible from all intended hosts. Review VMkernel connectivity, cluster configuration, CPU compatibility, and other vMotion or HA requirements.
Intermittent iSCSI connectivity or poor performance
- Likely causes: Congested or incorrectly configured storage networking, inconsistent VLAN or MTU settings, physical-switch errors, incorrect port binding, or only one active path.
- Checks: Validate end-to-end network settings and isolation. Review active paths, adapter status, switch errors, and array logs. Compare the design with the supported configuration for the ESXi release and array.
NFS datastore cannot be mounted
- Likely causes: The NAS is unreachable from the ESXi VMkernel interface, the export path or NFS version is incorrect, or export permissions deny the host.
- Checks: Confirm IP reachability and DNS behavior when names are used. Verify the exact path, supported NFS version, and host authorization.
Datastore loses paths after maintenance
- Likely causes: Redundant paths were not configured correctly, an HBA, cable, switch, or storage-controller path failed, or a path-selection or array setting changed.
- Checks: Inspect path states and hardware-event logs. Test redundant components individually and confirm the configured multipathing policy.
Exam-relevant notes
- FC, FCoE, and iSCSI are block-storage protocols; NFS is a file-storage protocol.
- VMFS is commonly placed on block storage. NFS exports are mounted directly as NFS datastores.
- A LUN is not the same thing as a datastore. A LUN is a presented block-storage unit; a datastore is the ESXi logical container used for files.
- Local storage is tied to one host unless a separate design provides access elsewhere.
- Shared datastore visibility is a key prerequisite for common vMotion, HA restart, and DRS migration workflows.
- Multipathing improves resilience by providing alternate paths; it does not automatically make every storage design highly available.
Summary
Local storage is straightforward and useful for standalone, temporary, or low-priority workloads, but a host failure or hardware limitation can isolate it. Shared FC, FCoE, iSCSI, and NFS storage allows multiple ESXi hosts to access common datastores and supports resilient cluster designs.
The right choice depends on required performance, availability, budget, infrastructure, operational skills, and supported hardware and software versions. Regardless of protocol, consistent host access, capacity monitoring, security controls, redundant connectivity, and tested backup and recovery procedures are essential.