VMware ESXi and vSphere Cluster Management

VMware vSphere VMFS Datastores and Shared Storage

Learn how VMFS datastores provide shared block storage for ESXi, including locking, multipathing, vMotion, lifecycle management, snapshots, and troubleshooting.

VMware Virtual Machine File System (VMFS) is VMware's clustered file system for block storage presented to ESXi hosts. A VMFS datastore gives virtual machines and ESXi a consistent storage container while allowing multiple hosts to access the same datastore safely.

This shared-storage model is central to many vSphere capabilities, including vMotion, vSphere HA, DRS, and Storage vMotion. VMFS is not the only datastore type, and shared visibility alone does not make every clustered service available. Networking, compatibility, licensing, cluster configuration, and storage design are also required.

What VMFS Is and What a Datastore Stores

A datastore is a vSphere storage container that presents capacity from an underlying device or storage service to ESXi hosts and virtual machines. With VMFS, the underlying storage is block-based, such as a LUN from a storage array or a supported local block device.

VMFS acts as an abstraction layer between ESXi and the block device. ESXi does not place virtual-machine files directly on an unmanaged LUN. Instead, an administrator formats the device with a compatible VMFS version and creates a named datastore.

A VMFS datastore can contain:

Virtual-machine configuration files.
Virtual disks, commonly represented by VMDK files.
Virtual-machine log files.
Snapshot delta files and related metadata.
Virtual-machine swap files where applicable.
Templates, ISO images, and other files used by the virtual infrastructure.

VMFS is designed for clustered virtualization workloads. Its metadata and locking mechanisms coordinate access from multiple ESXi hosts instead of assuming that only one operating system instance can write to the file system.

VMFS Compared with Conventional File Systems

Many conventional physical file systems are normally mounted read-write by one operating system or one host. If another host accesses the same block device without special coordination, file-system structures can be corrupted.

VMFS is designed for concurrent access by multiple ESXi hosts. This does not mean that every host may freely modify every byte at the same time. VMFS coordinates metadata changes with distributed locking and uses journaling to help maintain consistency after interruptions.

Characteristic	Conventional single-host file system	VMFS datastore
Typical read-write ownership model	One host or operating-system instance usually owns the mounted file system.	Multiple ESXi hosts can mount and access the same datastore.
Concurrent host access	Usually requires a cluster-aware design or a specialized shared-file-system implementation.	Designed for coordinated concurrent access by ESXi hosts.
Metadata coordination	Managed within the host that mounted the file system.	Coordinated across hosts using VMFS locking and metadata mechanisms.
Primary workload	General files, applications, or operating-system volumes.	Virtual-machine files, virtual disks, logs, snapshots, and swap files.
Role in clustered virtual infrastructure	Does not automatically provide safe shared VM storage.	Provides a shared file system for eligible vSphere cluster services.

In a vSphere cluster, shared access is needed because a virtual machine may need to run on a different ESXi host after a live migration, a host failure, or a workload-balancing decision. The destination host must be able to open the same virtual-machine files.

Shared-Storage Architecture

A typical VMFS design has several layers:

Multiple ESXi hosts provide compute resources.
A storage array provides block devices, often called LUNs.
A storage fabric or IP network connects each host to the array.
Each participating host discovers the same LUN through consistent presentation.
One host creates a VMFS datastore on the LUN, and the datastore is mounted by the other eligible hosts.

A LUN is a logical block-storage device presented by a storage system to one or more hosts. The LUN is not itself a VMFS datastore until it is formatted with VMFS.

Shared storage requires consistent visibility. Array-side zoning, LUN masking or mapping, host initiator authorization, and host-side adapter configuration must all allow the intended ESXi hosts to access the same device. A datastore visible to only one host is effectively a host-specific resource and cannot support cluster operations that require shared access.

Foundational design checks include:

Zoning: Controls which Fibre Channel or FCoE initiators can communicate with storage targets.
LUN masking or mapping: Controls which hosts or host groups can access a particular LUN.
Multipathing: Provides multiple physical or logical paths between an ESXi host and storage.
Path selection policy: Determines how ESXi chooses among available storage paths.
Uniform presentation: Ensures that all intended hosts see the same shared device and datastore.

A host-local datastore is different: it is backed by storage accessible only to one ESXi host, such as a local disk. It can store virtual machines, but it cannot by itself provide the shared-storage foundation required for many cluster services.

Storage Protocols and Datastore Types

VMFS is a file-system format for block storage. The block device can be accessed through Fibre Channel, Fibre Channel over Ethernet (FCoE), iSCSI, or supported local block devices.

Fibre Channel is a storage networking protocol commonly used in SANs. FCoE transports Fibre Channel traffic over Ethernet. iSCSI carries SCSI block-storage commands over an IP network.

NFS is different. An NFS datastore is a file-based datastore mounted from an NFS server. It is not formatted with VMFS, although it can provide shared datastore access to multiple ESXi hosts.

Storage access type	Common protocols	Datastore format	Shared access capability	Key design note
Block storage	Fibre Channel, FCoE, iSCSI	VMFS created on a LUN or block device	Yes, when consistently presented to hosts	Requires fabric or network connectivity, LUN presentation, and multipathing.
File storage	NFS	NFS datastore; not VMFS	Yes, when the export is correctly accessible	Depends on NFS network design, export permissions, and server resiliency.
Local storage	Local disks or supported local controllers	VMFS or another supported local datastore format	Normally limited to the host that owns the device	Does not provide shared storage unless an additional supported architecture is used.

Protocol choice affects fabric or network configuration, authentication, redundancy, monitoring, vendor integration, and operational procedures. For example, iSCSI requires suitable VMkernel networking and target discovery, while Fibre Channel requires correctly configured HBAs, switches, and zoning. Use the storage vendor's supported design and the compatibility guidance for the deployed vSphere release.

Concurrency, Locking, Metadata, and Recovery

Metadata is file-system information describing files, directories, allocation, and datastore structure. Multiple ESXi hosts may need to update metadata when they create files, change file sizes, allocate blocks, or perform other datastore operations.

VMFS uses distributed locking to coordinate these updates. A host obtains the appropriate lock before changing shared metadata, preventing conflicting operations from corrupting the datastore structure. VMFS also uses journaled metadata changes. Journaling records changes in a way that supports consistency and recovery after a host crash, power interruption, or storage disruption.

Virtual-machine files have additional protection. File-level locking helps identify which host currently owns active execution of a virtual machine's files. A VM may be visible to several hosts, but it normally has one active execution owner. Shared visibility is therefore not permission for multiple hosts to run the same VM concurrently.

Where supported by the storage device, ATS (Atomic Test and Set) can provide a hardware-assisted primitive for VMFS locking. VAAI (vStorage APIs for Array Integration) exposes selected storage offload and assistance capabilities. ATS or VAAI can improve or assist operations, but neither replaces correct zoning, LUN presentation, multipathing, firmware, compatibility, or array design.

After a failure, the surviving hosts use the datastore's consistency and locking mechanisms to determine the state of operations and continue with safe access. Recovery behavior depends on the failure type, storage availability, vSphere version, and array implementation.

vSphere Services Enabled by Shared VMFS

vMotion

vMotion moves the compute execution of a running virtual machine from one compatible ESXi host to another. With shared VMFS storage, the virtual-machine files remain accessible while execution moves between hosts. The hosts still require compatible CPU features, suitable VMkernel networking, correct cluster configuration, and no blocking VM device or policy constraints. See Enhanced vMotion Explained and CPU Compatibility for vMotion.

Storage vMotion

Storage vMotion moves a virtual machine's files from one datastore to another. It is a storage migration operation, not merely a compute migration. The destination datastore must have adequate capacity, compatibility, and access, and the operation must account for virtual disks, snapshots, configuration files, and swap files.

DRS and vSphere HA

DRS balances virtual-machine workloads across hosts. Shared storage helps DRS move workloads without first copying all VM files to a host-local disk. DRS still requires an appropriately configured cluster and supported licensing and compatibility.

vSphere HA restarts affected virtual machines on available hosts after an ESXi host failure when HA, admission control, networking, compatibility, and storage prerequisites are met. The surviving host must be able to access the VM's files. Shared VMFS is therefore an important dependency, but VMFS alone does not enable HA. Review Enable vSphere HA and Admission Control Explained.

vSphere Fault Tolerance

vSphere Fault Tolerance (FT) maintains a protected execution relationship between hosts for supported virtual machines. It has specific CPU, networking, storage, VM configuration, capacity, compatibility, and licensing requirements. Shared VMFS may be part of the storage design, but it does not by itself provide FT. See Enable vSphere FT and verify the requirements for the deployed release.

VMFS Datastore Lifecycle

Creation and mounting

The normal lifecycle begins when the storage administrator presents a block device to the intended ESXi hosts. In the vSphere Client, an administrator discovers the device, selects an eligible device, chooses a VMFS version compatible with the ESXi estate, names the datastore, and creates it. The datastore can then be mounted on other eligible hosts after verifying consistent device visibility.

Do not select a device for formatting until its identity, size, presentation, and intended use have been confirmed. Formatting the wrong device is destructive.

For a practical workflow, see Create VMFS Datastore and Browse VMFS Datastores.

Expansion

To expand an existing datastore using a larger backing LUN:

Increase the LUN size on the storage array according to the vendor procedure.
Rescan storage adapters on the relevant ESXi hosts.
Confirm that ESXi sees the expected new device capacity.
Use the datastore expansion workflow to consume the available space.
Verify capacity and path health on all intended hosts.

The LUN expansion and the VMFS expansion are separate operations. ESXi may see a larger device before the datastore has been expanded. See Expand VMFS Datastore and Increase Size of VMFS Datastore.

Extents

A datastore extent is an additional storage device added to a VMFS datastore. Extents can aggregate capacity, but they increase dependency on multiple devices and complicate failure analysis, monitoring, replacement, and capacity planning. Prefer the current supported expansion guidance for the deployed vSphere release and storage platform before adding an extent.

Capacity planning

Monitor free space rather than waiting for a datastore to become full. Consumption includes virtual disks, snapshot delta files, swap files, thin-provisioning growth, templates, logs, and VMFS overhead. Snapshot growth can be particularly rapid when a VM has sustained write activity.

Plan capacity for ordinary workload growth, temporary migration space, snapshot cleanup, host failure scenarios, and operational headroom. Use alarms and monitoring for capacity, latency, path state, and storage events.

Operation	Purpose	Main prerequisite	Primary risk or caution
Create datastore	Format an eligible block device with VMFS and name the datastore.	Correct device identity, compatible VMFS version, and approved storage presentation.	Formatting the wrong device destroys or overwrites data.
Mount datastore	Make an existing VMFS datastore available to another eligible host.	Consistent LUN visibility and compatible host configuration.	Incorrect identity handling can expose the wrong device.
Expand backing LUN and datastore	Increase usable datastore capacity.	Array expansion, rescan, and supported VMFS expansion workflow.	Expanding the wrong LUN or skipping validation can cause outages.
Add extent	Aggregate another device into a datastore.	Current VMware guidance and a carefully documented design.	Creates additional device dependencies and operational complexity.
Unmount or detach	Remove datastore access from a host or prepare storage for removal.	No active VMs, files, registrations, services, or paths depend on it.	Unplanned removal can cause VM failure or data loss.
Mount snapshot copy	Expose a point-in-time copy for recovery or testing.	Storage-vendor and vSphere-supported copy workflow.	Source and copy identities or data access can conflict.
Resignature copy	Assign a new VMFS identity to a detected copy.	Isolated or controlled presentation and an approved procedure.	Incorrect handling can make the copy confusing or unsafe to use.

VMFS Versions and Compatibility

VMFS versions provide different capabilities and compatibility boundaries. Select a version supported by every ESXi host that must mount the datastore and by the deployed vSphere release. Do not assume that a newer host can safely use every datastore feature when older hosts remain in the cluster.

Exact maximum sizes, feature availability, upgrade behavior, and supported workflows vary by vSphere release. Consult the documentation and compatibility information for the specific release and storage vendor.

Snapshot Copies, Replication, and Resignaturing

A storage array can create a point-in-time snapshot or replicated copy of a LUN containing a VMFS datastore. When that copy is presented to ESXi, the host detects that it has a VMFS signature associated with an existing datastore rather than automatically treating it as an unrelated new datastore.

A VMFS signature is an identifier used to distinguish a datastore and detect copied or replicated instances. The administrator may need to mount the replica using an approved workflow or perform resignaturing, which assigns a new signature to the copy.

Do not casually present both the original and copied devices to the same environment. Simultaneous visibility can create identity confusion and, depending on the workflow, data-consistency risks. Before mounting a copy:

Identify whether the device is a snapshot, clone, replica, or original LUN.
Confirm the storage vendor's supported snapshot-mount procedure.
Use an isolated recovery host or controlled environment when appropriate.
Determine whether the copy should be mounted with its existing identity or resignatured.
Register or power on recovered virtual machines only after validating their files and network behavior.

Never improvise a replicated-datastore workflow. Validate it against the storage vendor's instructions and the vSphere documentation for the deployed release.

Availability, Performance, and Operational Design

Availability

A resilient design removes single points of failure across the entire path:

Use redundant storage adapters, controllers, switches, links, and array components where supported.
Configure multiple paths from each ESXi host to the storage.
Use the storage vendor's supported path selection policy.
Separate and protect storage networks or fabrics according to the design.
Validate path states after maintenance and failure testing.

Multipathing can provide failover and, with a suitable policy and array support, distribute I/O across paths. It does not correct a failed switch, misconfigured zoning, incorrect LUN masking, or an overloaded array.

Performance

Important performance factors include storage latency, queue depth, path health, array controller and disk or flash performance, datastore contention, virtual-disk layout, workload patterns, and snapshot growth. A healthy datastore can still perform poorly if many demanding VMs compete for the same array resources.

Investigate latency together with queue pressure, path changes, array metrics, host events, and network or fabric errors. Avoid treating a path-policy change as a universal performance fix.

Operational consistency

Hosts in a cluster should use consistent storage adapters, VMkernel configuration, zoning, LUN presentation, multipathing, firmware, and supported driver versions. Document changes, use maintenance windows, maintain backups, monitor alarms, and test recovery procedures.

Never reformat, repartition, detach, or unmount a VMFS datastore while it is in use. Confirm that no virtual machines, templates, ISO files, snapshots, swap files, host services, or cluster operations depend on the datastore.

Useful ESXi Storage Checks

After presenting or expanding storage, rescan adapters and compare the results across hosts. These commands are diagnostic examples; use appropriate privileges and confirm the target device before taking any modifying action.

esxcli storage core adapter rescan --all
esxcli storage filesystem list
esxcli storage core path list
esxcli storage core device list
esxcli storage vmfs extent list

esxcli storage core adapter rescan --all rescans storage adapters.
esxcli storage filesystem list lists mounted file systems and datastores.
esxcli storage core path list shows storage paths and their states.
esxcli storage core device list lists discovered storage devices.
esxcli storage vmfs extent list shows VMFS datastore extents.

Troubleshooting VMFS and Shared Storage

Datastore visible on one host only

Likely causes include inconsistent zoning, LUN masking or mapping, missing iSCSI, Fibre Channel, or FCoE connectivity, a host adapter that has not been rescanned, or incorrect host-side network or fabric configuration.

Compare device visibility and path lists on working and affected hosts.
Validate array-side presentation and initiator authorization.
Check adapter, VMkernel, fabric, switch, and authentication configuration.
Rescan adapters after correcting the presentation or connectivity.

Datastore copy detected as a snapshot or replica

The copied device may retain the source VMFS signature, both source and copy may be visible in the same environment, or the storage snapshot workflow may be incomplete. Identify the copy and follow the approved mount or resignature procedure. Do not take actions that could make the copy appear to be the production source.

New capacity is not visible

Confirm that the array-side LUN expansion completed. Then rescan the ESXi storage adapters, verify the device size, and expand the VMFS datastore. Seeing the larger device does not necessarily mean that VMFS has already consumed the additional space.

vMotion or HA is unavailable

Shared VMFS is only one prerequisite. Check vMotion VMkernel networking, host CPU and feature compatibility, cluster membership, HA or DRS status, licensing, admission control, VM configuration, and any connected-device constraints. See Create Clusters, Enable DRS, and Set DRS Automation Level.

High latency or intermittent path failures

Inspect path state, latency metrics, storage events, and array health. Possible causes include failed SAN or Ethernet components, HBAs, NICs, cables, incorrect path policies, array contention, queue pressure, oversubscription, or a host configuration mismatch. Restore redundancy before performing disruptive remediation.

Practical Examples

Two-host cluster using a shared SAN LUN

Two ESXi hosts are authorized to access the same iSCSI or Fibre Channel LUN. One host formats the LUN as VMFS, and the datastore is mounted by both hosts. A VM stored there can move between compatible hosts with vMotion when networking, CPU compatibility, cluster configuration, and VM requirements are satisfied.

Expanding a datastore

An administrator increases the backing LUN size on the array, rescans storage adapters, confirms the new capacity, and expands the existing VMFS datastore. The VM can remain online when the storage platform and vSphere workflow support online expansion, but the procedure must still be planned and validated.

VMFS and NFS comparison

A block LUN presented over iSCSI is formatted with VMFS. An NFS export is mounted directly as an NFS datastore and is not formatted with VMFS. Both can be shared, but VMFS uses block-device access and VMFS metadata, while NFS uses a file-server protocol and NFS export semantics.

Recovery validation with an array snapshot

A storage administrator creates a point-in-time copy of a VMFS-backed LUN and presents it to an isolated recovery host. ESXi detects the copied identity. The administrator follows the approved snapshot-mount or resignaturing workflow, validates the recovered files, and avoids simultaneous unsafe access to the source and copy.

Host failure

One host running a VM fails. Other hosts retain access to the shared VMFS datastore, so vSphere HA can restart the VM on an available host if HA, admission control, networking, compatibility, and storage prerequisites are correctly configured.

Limitations and Safety Boundaries

Shared datastore visibility does not mean that multiple hosts can run the same VM concurrently.
VMFS should not be reformatted, repartitioned, detached, or unmounted while it is in use.
VMFS is one vSphere datastore option. NFS, vSAN, local storage, and other supported choices may be more appropriate for particular requirements.
Exact features, limits, maximums, and supported workflows vary by vSphere release and storage vendor.
ATS and VAAI assistance cannot compensate for incorrect storage presentation or an inadequate resiliency design.

Summary

VMFS provides the shared, clustered file-system layer that lets multiple ESXi hosts access virtual-machine files on block storage. Correct implementation depends on consistent LUN presentation, zoning or network configuration, multipathing, compatible VMFS versions, monitoring, and safe lifecycle procedures.

When those foundations are combined with the required compute, networking, licensing, and cluster configuration, shared VMFS datastores support services such as vMotion, Storage vMotion, DRS, and vSphere HA. For related storage work, see Configure iSCSI Software Initiator, Fibre Channel Overview, and Configure NFS Datastore.