VMware ESXi and vSphere Cluster Management

VMware vSphere VMFS: Shared Datastores for ESXi Hosts

Learn how VMware VMFS provides shared block-storage datastores for ESXi, including locking, protocols, vSphere features, capacity management, recovery, and troubleshooting.

VMware Virtual Machine File System (VMFS) is VMware's clustered file system for datastores built on supported block storage. It lets multiple ESXi hosts access the same datastore while coordinating metadata and file operations.

This shared access is foundational to many vSphere capabilities. When hosts can reach the same VMFS datastore, a virtual machine's files can remain available while vSphere moves or restarts the virtual machine on another host. VMFS is not, however, a replacement for backups, replication, or disaster-recovery planning.

What VMFS Is and What It Stores

A datastore is a logical storage container presented to ESXi for virtual machine files and related objects. VMFS is the file system used to organize files in a datastore on supported block devices.

A VMFS datastore can contain:

  • Virtual disks, commonly stored as VMDK files
  • Virtual machine configuration files
  • Snapshot delta files
  • Virtual machine log files
  • Virtual machine swap files
  • Other files associated with virtual machines and vSphere operations

VMFS is designed for a situation in which several ESXi hosts need to mount one datastore. Each host sees the datastore as an accessible storage location, while VMFS coordinates operations that affect shared file-system structures.

The Shared-Storage Architecture

The storage stack has several distinct layers. Confusing these layers is a common source of configuration errors.

  1. A storage array provides physical storage capacity.
  2. The array presents a LUN, which is a logical block-storage unit, to one or more ESXi hosts.
  3. A transport such as Fibre Channel, FCoE, or iSCSI carries block commands between the hosts and the storage system.
  4. ESXi detects the block device and can format it with VMFS.
  5. The resulting VMFS datastore provides folders and files for virtual machines.

For example, a storage administrator might present the same iSCSI LUN to two ESXi hosts. After storage discovery and rescans, both hosts detect the same device. An administrator creates or mounts a VMFS datastore on that device, and both hosts can access the datastore.

The important distinction is that the LUN is block storage, while the VMFS datastore is the file system created on top of that block device.

Why Shared Datastores Matter in a Cluster

A vSphere cluster may contain several ESXi hosts. If a virtual machine's files are stored on a datastore visible to only one host, another host cannot normally open those files after a host failure or during a migration. A shared VMFS datastore makes the files accessible to multiple hosts.

Shared visibility is only one requirement. Hosts also need compatible CPU and virtual hardware settings, suitable networking, correct permissions, supported storage paths, and properly configured vSphere features.

VMFS Compared with Conventional File Systems

Many conventional local file systems are designed around a single computer owning a storage device. That host can read and write the file system, while another host accessing the same device without coordination could corrupt file-system metadata.

VMFS is designed for coordinated multi-host access. Multiple ESXi hosts can mount one datastore and perform operations such as opening different virtual machine files, creating files, updating directories, and checking datastore state. VMFS uses distributed metadata management, locks, and storage coordination primitives to control those operations.

Concurrent datastore access does not mean that several hosts should make uncontrolled changes to the same individual virtual machine files. A virtual disk still needs controlled ownership and coordination. VMFS locking helps prevent conflicting metadata updates and unsafe virtual disk operations.

Locks and Coordination

VMFS locking identifies operations that must be serialized. For example, a host opening a virtual machine's files must not conflict with another host attempting an incompatible operation on those same files. The exact implementation depends on the VMFS version, storage capabilities, and ESXi release.

Older VMFS environments used SCSI reservations more extensively. Reservations can temporarily restrict access to a device while a host performs a sensitive operation, but excessive use can affect other workloads. Modern environments may use ATS, or Atomic Test and Set, when the storage supports it. ATS allows more granular locking of VMFS metadata regions.

VAAI, or vSphere APIs for Array Integration, provides storage-array integration and offload capabilities. Compatible arrays and hosts can use supported primitives to improve operations such as locking or data movement. Always verify support with the storage vendor and the relevant VMware compatibility documentation.

Storage Protocols and Datastore Types

Common block-storage transports for VMFS include Fibre Channel, Fibre Channel over Ethernet, and iSCSI.

  • Fibre Channel (FC): A SAN protocol that provides block storage over a dedicated Fibre Channel fabric.
  • FCoE: Fibre Channel traffic transported over Ethernet infrastructure.
  • iSCSI: A protocol that transports SCSI block commands over IP networks.
  • Local disks: A local block device can support a VMFS datastore, but that datastore is not shared with other hosts unless the storage architecture specifically provides shared access.

An NFS datastore is different. NFS is network file storage: ESXi mounts an exported file share rather than formatting a block LUN with VMFS. NFS datastores therefore do not use VMFS as their datastore file system.

Storage Protocol and Datastore Clarification

Fibre Channel — Block access; can back VMFS; commonly used with SAN zoning, host bus adapters, and array-based LUN presentation.

FCoE — Block access; can back VMFS; carries Fibre Channel traffic over Ethernet and requires compatible network and storage infrastructure.

iSCSI — Block access; can back VMFS; depends on IP reachability, discovery, authentication, VMkernel configuration, and suitable multipathing.

NFS — File access; does not back a VMFS datastore; ESXi mounts an exported network file share as an NFS datastore.

Metadata, Journaling, and Distributed Locking

Metadata is information describing files, directories, allocation, ownership, and datastore state. Because several hosts can access a VMFS datastore, metadata updates must be coordinated across hosts rather than treated as purely local changes.

VMFS uses distributed metadata mechanisms and journaling at a conceptual level. A journal records file-system changes or operations in a way that helps the file system determine what was completed and what may need recovery after a host crash, storage interruption, or hardware failure.

Journaling does not prevent every storage failure and does not guarantee that application data is recoverable. It helps maintain file-system consistency so the datastore can recover in an orderly way.

Why Consistent LUN Presentation Is Essential

Every host intended to use a shared datastore must receive the same storage device consistently. Zoning, masking, access control, target discovery, and device identifiers must be correct. A host that sees a different device, an incomplete device, or no device at all cannot safely participate in shared datastore operations.

Multipathing provides multiple storage paths between an ESXi host and a storage device. Redundant paths improve availability and may provide performance benefits depending on the path-selection policy and array design. Multipathing does not correct incorrect LUN masking or inconsistent presentation.

vSphere Features Enabled by Shared VMFS

Shared Storage Features and Dependencies

vMotion — Shared VMFS can keep virtual machine files accessible while a running VM moves between compatible hosts. Additional requirements include vMotion networking, CPU compatibility, licensing, permissions, and compatible configuration.

Storage vMotion — VMFS provides one possible source or destination datastore for moving virtual machine files. It also requires supported storage, adequate capacity, networking, permissions, and workload compatibility.

DRS — Shared storage allows DRS to place or balance workloads across hosts without first copying every VM file to a host-local disk. DRS also depends on licensing, cluster configuration, host compatibility, and resource data.

vSphere HA — If a host fails, HA can restart affected virtual machines on another host when their files are accessible on shared storage. HA admission control, cluster health, networking, capacity, and VM configuration are also required.

Fault Tolerance — Shared storage can be part of an environment supporting Fault Tolerance, but VMFS alone does not provide FT. FT has specific host, networking, licensing, VM, and compatibility requirements.

These features do not come from VMFS in isolation. Availability depends on vSphere licensing, host and vCenter versions, CPU compatibility, VMkernel networking, storage performance, permissions, cluster configuration, and other release-specific requirements.

Example: Two-Host SAN-Backed Cluster

  1. Present the same iSCSI or Fibre Channel LUN to both ESXi hosts.
  2. Configure the required zoning, masking, discovery, authentication, and network or SAN paths.
  3. Rescan storage adapters on both hosts.
  4. Verify that both hosts detect the same device and have healthy paths.
  5. Create a VMFS datastore on the discovered block device, or mount the existing datastore.
  6. Confirm that both hosts show the datastore as accessible.
  7. Place a virtual machine on the datastore and verify that the cluster's migration and HA prerequisites are satisfied.

Creating and Managing VMFS Datastores

In the vSphere Client, create a datastore by selecting a discovered supported block device and choosing a supported VMFS format. The workflow typically includes selecting the host or cluster context, naming the datastore, selecting the device, choosing the VMFS version offered by the release, and confirming the partitioning and formatting operation.

After creation, review the datastore's connected hosts, capacity, free space, accessibility, alarms, paths, and backing device identifiers. Use meaningful names and keep a record that maps datastore names to array devices or LUN identifiers.

VMFS Capacity Expansion

Increasing capacity has two separate stages:

  1. Expand the backing LUN: The storage array increases the size of the block device.
  2. Expand the VMFS datastore: ESXi recognizes the larger device and the VMFS file system is expanded to consume the additional space.

Expanding the LUN does not automatically mean that the datastore is expanded. ESXi may need a storage rescan first, followed by the supported datastore expansion workflow.

Datastore expansion can often be performed online, allowing existing virtual machines to remain operational. Nevertheless, plan the change, confirm compatibility, check the storage vendor's procedure, and maintain current backups.

Extents

A VMFS extent is additional storage capacity associated with a datastore. Adding an extent can increase available capacity, but it introduces another device dependency and can complicate monitoring, recovery, and retirement. Resizing and extent operations require planning and compatibility checks. Do not treat extents as a substitute for a well-designed capacity plan.

VMFS Capacity Operations

Expand backing LUN — Change the storage array or block device; usually online; verify the new size on the array and after an ESXi rescan; confirm the correct device before changing it.

Expand VMFS datastore — Change the VMFS file system on the discovered device; commonly online; verify datastore capacity and free space; expansion of the LUN alone is insufficient.

Add extent — Associate another supported block device with VMFS; downtime depends on the procedure and workload; inspect extent membership and capacity; plan for extra operational complexity.

Present copied datastore — Change storage presentation and datastore identity; isolate the copy first; verify device identity and mount state; avoid exposing an ambiguous copy alongside its original.

Remove or retire datastore — Remove VM and other files, then remove storage presentation according to procedure; confirm that no host or VM depends on it; data loss is possible if dependencies are missed.

Capacity Monitoring and Snapshots

Monitor total capacity, free-space headroom, growth rate, latency, path health, and alarms. Avoid operating a datastore near full capacity because VM operations, snapshots, logs, swap files, and management tasks may require temporary space.

Snapshots are point-in-time references that usually create delta files as the guest continues to change. Long-lived or rapidly growing snapshots can consume substantial datastore capacity and increase storage I/O. Use snapshots for short, controlled purposes and monitor their age and size.

Point-in-Time Copies, Replicas, and Resignaturing

A storage-array snapshot or replica is a point-in-time copy of a datastore or its underlying storage. Such a copy can support testing, recovery, or other operational procedures, but presenting it to ESXi requires careful identity management.

A copied VMFS datastore may retain the original datastore signature. If ESXi sees both the original and the copy with the same identity, it may detect the copy as a snapshot volume or refuse to mount it normally. Mounting both identities without a validated procedure can create ambiguity and risk unintended access to the wrong virtual machine files.

Resignaturing assigns a new VMFS datastore signature to a storage copy. Whether to mount the copy without changing its identity or resignature it depends on the recovery goal, the ESXi release, the storage system, and whether the original remains accessible.

Safe Recovery-Copy Workflow

  1. Present the snapshot or replica only to an isolated recovery or test host when possible.
  2. Identify the original device and the copied device using storage identifiers, array information, and ESXi inspection tools.
  3. Check whether ESXi detects the copy as a snapshot volume.
  4. Choose the appropriate mount or resignature procedure for the intended recovery scenario.
  5. Validate datastore contents, virtual machine registrations, network isolation, and application behavior before production use.
  6. Follow the storage vendor's recovery guidance and document every identity or presentation change.

VMFS Versions and Operational Considerations

VMFS versioning affects supported features, limits, and management behavior. VMFS5 and VMFS6 are commonly encountered in vSphere environments, but the exact capabilities depend on the ESXi and vCenter releases involved.

Before creating, upgrading, expanding, or migrating a datastore, check current VMware documentation for the release-specific limits and supported upgrade paths. Do not infer support solely from the datastore name or from another environment running a different release.

Good operational practice includes:

  • Use unique, meaningful datastore names.
  • Verify visibility and accessibility from every intended host.
  • Maintain consistent LUN presentation across cluster hosts.
  • Configure redundant paths and investigate degraded path states promptly.
  • Review datastore alarms, latency, capacity, and snapshot growth.
  • Record backing device identifiers and storage ownership.
  • Validate array firmware, ESXi versions, drivers, and VAAI support against compatibility guidance.
  • Perform storage changes with a tested rollback or recovery plan.

Useful ESXi Inspection Commands

These commands are useful for inspection from an ESXi shell. Use change commands only when you understand their effect and have an approved maintenance procedure.

esxcli storage filesystem list

Lists mounted file systems and datastore details.

esxcli storage core device list

Displays storage devices detected by the ESXi host.

esxcli storage core path list

Shows storage paths and their states for multipathing validation.

esxcli storage vmfs extent list

Displays the device extents associated with VMFS datastores.

esxcli storage core adapter rescan --all

Rescans all storage adapters after storage presentation or capacity changes.

The equivalent vSphere Client workflow is often preferable for controlled administration: rescan storage adapters, inspect devices and paths, create or mount the datastore, expand the datastore when appropriate, and review capacity and accessibility from all intended hosts.

Troubleshooting VMFS Environments

Datastore Visible to One Host but Not Another

Likely causes include incomplete LUN masking or zoning, a missing storage rescan, inconsistent iSCSI discovery or authentication, network reachability problems, or Fibre Channel fabric and HBA issues.

  • Compare detected devices and paths on both hosts.
  • Rescan storage adapters.
  • Validate zoning, masking, target access, VLANs, VMkernel bindings, and authentication as applicable.
  • Confirm that both hosts are intended to receive the same LUN.

Datastore Capacity Did Not Increase

Confirm the new LUN size on the storage array. Rescan ESXi adapters and inspect the device capacity. If ESXi sees the larger device but the datastore remains unchanged, perform the supported VMFS expansion workflow after confirming backups and the maintenance plan.

Copied Datastore Appears as a Snapshot Volume

The copy may retain the original VMFS identity, or the original datastore may still be visible to the host. Identify both devices, isolate recovery storage where possible, and use the appropriate mount or resignature process according to the recovery objective and vendor guidance.

Virtual Machines Cannot Migrate Between Hosts

Verify that the destination host can access the same datastore. Then validate vMotion VMkernel connectivity, CPU compatibility, licensing, cluster configuration, permissions, and the virtual machine's settings. Shared storage alone does not satisfy every migration requirement.

Latency or Intermittent Storage Errors

Inspect path states, storage events, and latency at both host and array levels. Check physical links, SAN switches, HBAs, iSCSI networking, array contention, queueing, capacity, and multipathing policy. A healthy VMFS file system cannot compensate for an overloaded array or a failing transport path.

VMFS Compared with Other ESXi Datastore Types

VMFS on FC or FCoE — Backing storage: SAN LUN; access model: shared block access; formatted with VMFS: yes; typical use: clustered VM storage; considerations: zoning, masking, HBAs, fabric health, and multipathing.

VMFS on iSCSI — Backing storage: iSCSI LUN; access model: shared block access over IP; formatted with VMFS: yes; typical use: shared VM storage using an IP SAN; considerations: VMkernel networking, discovery, authentication, MTU consistency where applicable, and path redundancy.

VMFS on local block storage — Backing storage: host-local disk; access model: generally single-host; formatted with VMFS: yes; typical use: host-local workloads or boot and scratch-related designs; considerations: no shared datastore access between ordinary separate hosts and reduced host-failure mobility.

NFS datastore — Backing storage: exported network file share; access model: file access over the network; formatted with VMFS: no; typical use: shared file-based datastore; considerations: NFS version, network availability, permissions, and storage appliance behavior.

vSAN datastore — Backing storage: storage contributed by vSAN cluster hosts; access model: distributed storage architecture; formatted with VMFS: no; typical use: hyperconverged vSphere storage; considerations: vSAN design, networking, disk groups or storage pools, policies, and cluster compatibility.

Design Limits and Performance Scope

VMFS is one datastore option among NFS, vSAN, and other supported architectures. The right choice depends on operational requirements, array capabilities, performance targets, protection objectives, and the skills available to manage the environment.

VMFS does not determine storage performance by itself. Performance depends on array design, media, cache, controllers, SAN or network configuration, pathing, queueing, device contention, VM layout, snapshot activity, and workload behavior. Measure latency and throughput at both the ESXi and storage-system layers.

VMFS also does not provide backups, application-consistent recovery, storage replication, or disaster recovery by itself. Use an appropriate backup system, replication design, recovery runbook, and regular recovery testing.

Exam-Relevant Summary

  • VMFS is VMware's clustered file system for datastores on supported block storage.
  • A datastore is a logical container for VM files; a LUN is a block-storage unit beneath the datastore.
  • Multiple ESXi hosts can mount one shared VMFS datastore, but file operations still require coordination and locking.
  • FC, FCoE, and iSCSI can provide block storage for VMFS. NFS provides a file-based datastore and is not formatted with VMFS.
  • ATS and VAAI can improve locking or storage integration when supported by the host and array.
  • Shared VMFS can contribute to vMotion, Storage vMotion, DRS, and HA, but each feature has additional requirements.
  • Expanding a LUN and expanding the VMFS datastore are separate operations.
  • A copied VMFS datastore may require isolation, mounting decisions, or resignaturing before use.
  • VMFS version capabilities and limits depend on the ESXi and vCenter release.
  • VMFS is not a backup or disaster-recovery solution.

For a concise reference, see VMware vSphere VMFS.