Vmware Esxi

VMware VMFS: Virtual Machine File System and ESXi Datastores

Learn how VMware VMFS organizes virtual machine files, enables shared ESXi storage, and supports vMotion, HA, DRS, thin disks, RDM, and datastore planning.

VMware Virtual Machine File System (VMFS) is VMware's clustered file system for storing virtual machine files. In an ESXi environment, VMFS is normally created on SCSI-based block storage and exposed to ESXi as a datastore.

VMFS is not the same thing as a disk, LUN, or storage array. A LUN is a logical storage unit presented by a storage system. ESXi formats an eligible block device or LUN with VMFS, and the resulting datastore becomes the logical storage container that ESXi uses for virtual machine files.

This distinction is important: the storage array provides physical or logical capacity, VMFS organizes that capacity, and ESXi and vCenter use the datastore to place and manage virtual machines.

What VMFS Does in ESXi

Storage virtualization separates a guest operating system from the physical storage hardware. A virtual machine does not normally interact with a Fibre Channel target, iSCSI target, or local disk directly. Instead, ESXi presents virtual storage hardware to the guest and translates the guest's I/O into operations on files or mapped devices.

For a normal virtual disk, VMFS stores a VMDK file. ESXi presents that VMDK to the guest as a virtual SCSI disk. The guest operating system then creates and manages its own file system inside that virtual disk, such as NTFS, ext4, or XFS.

The guest does not use VMFS to store its files. VMFS is below the VMDK layer; the guest file system is inside the VMDK.

How a VMFS Datastore Organizes Virtual Machine Data

A VMFS datastore contains directories for virtual machines and related VMware objects. A typical virtual machine directory can contain:

• VMDK files: virtual disk data and, commonly, a small descriptor file that identifies the disk's layout.
• VMX configuration file: the virtual machine's configuration and virtual hardware settings.
• Log files: records of virtual machine and virtual hardware activity.
• VMEM or swap files: files that may be created for virtual machine memory state or ESXi memory swapping, depending on configuration and conditions.
• Snapshot files: delta disks and related metadata created when a snapshot is present.
• Metadata and support files: files used by ESXi to track virtual machine state, locks, snapshots, and other operations.

Encapsulating a virtual machine in a datastore directory simplifies copying, registering, protecting, migrating, and recovering the VM. It does not mean every VM operation is merely a file copy; ESXi must maintain virtual disk consistency, locks, metadata, and compatibility.

VMFS as a Clustered Shared File System

Multiple ESXi hosts can concurrently read from and write to the same shared VMFS datastore. This is the defining difference between a shared VMFS datastore and a local file system mounted by only one operating system.

Concurrent access requires coordination. VMFS uses metadata coordination and locking mechanisms to protect directory entries, virtual disk files, snapshots, configuration changes, and other shared structures. Metadata locking prevents two hosts from making conflicting changes to the same VMFS information at the same time.

Shared access allows a VM's files to remain available when the VM is placed on another compatible host. This supports centralized placement, recovery after host failure, and live migration. Shared access alone does not guarantee that every vSphere feature is available; networking, CPU compatibility, licensing, permissions, and feature-specific requirements still apply.

Shared versus local VMFS

A local VMFS datastore is created on storage attached to one ESXi host, such as a local disk or direct-attached enclosure. Other hosts cannot use it unless they also have a supported, consistent path to the same backing storage.

A shared datastore is backed by storage presented consistently to multiple hosts. Each intended host must see the same device identity and have suitable paths to it. Storage presentation, zoning, LUN masking, iSCSI networking, multipathing, and host rescans all matter.

VMFS Capabilities and Their vSphere Outcomes

VMFS and vSphere Availability and Mobility

vMotion

vMotion migrates a powered-on virtual machine between compatible ESXi hosts. Shared VMFS storage allows the source and destination hosts to access the VM's files from the same datastore, so the VM's storage does not need to be copied during an ordinary compute-only migration.

Shared VMFS is a storage prerequisite for many traditional vMotion designs, but it is not the only prerequisite. Check CPU compatibility, networking, VM configuration, permissions, licensing, and cluster policy. See CPU compatibility for vMotion and Enhanced vMotion for related requirements.

vSphere HA

vSphere HA can restart affected virtual machines on another host after an ESXi host failure. Shared VMFS makes the VM's configuration and virtual disks available to the recovery host. HA still requires a correctly configured cluster, host communication, admission control, compatible destination capacity, and appropriate networking. Review enabling vSphere HA and datastore heartbeating.

DRS

Distributed Resource Scheduler (DRS) makes placement and balancing decisions across cluster hosts. A shared datastore gives DRS and the cluster a common storage location that remains reachable as a VM changes hosts. DRS decisions also depend on CPU, memory, affinity rules, host compatibility, storage performance, and cluster configuration. See enabling DRS and setting the DRS automation level.

Fault Tolerance

Fault Tolerance provides a specialized availability mechanism with additional requirements for VM configuration, CPU compatibility, networking, storage, performance, and supported versions. A VMFS datastore by itself does not make a VM eligible for Fault Tolerance. Consult the requirements for vSphere Fault Tolerance before designing around it.

VMFS Versions and Historical VMFS-5 Characteristics

VMFS capabilities, limits, upgrade behavior, and supported devices vary by vSphere release. Always verify the current VMware documentation for the exact ESXi and vCenter versions being designed or deployed.

Historically, VMFS-5 was commonly described with a 1 MB block size, virtual disk support up to approximately 62 TB, datastore sizing up to 64 TB, and up to 256 VMFS datastores per host. These figures are historical design references, not universal limits for every current release or storage configuration.

Do not size a datastore using only one limit. Consider total datastore capacity, maximum individual file size, number of datastores per host, VM count, snapshot growth, free-space headroom, storage-array limits, path limits, backup behavior, and expected workload growth.

Datastore Design and Capacity Planning

• Choose descriptive names that identify purpose, performance tier, site, or cluster without becoming ambiguous.
• Reserve headroom for VM growth, snapshots, swap files, templates, maintenance, and unexpected allocation spikes.
• Distribute workloads according to capacity, IOPS, throughput, latency, failure domains, and recovery requirements—not capacity alone.
• Document which hosts should see each datastore and verify that storage presentation is identical across those hosts.
• Monitor free space, latency, queueing, path health, device state, and storage-array alerts.
• Use permissions and role-based administration so only authorized operators can format, delete, detach, expand, or otherwise alter datastores. Review assigning permissions.

Thin provisioning and overcommitment

A thin-provisioned VMDK has a configured logical size but initially consumes only the datastore blocks needed for its contents. For example, five thin VMDKs configured at 2 TB each have 10 TB of logical capacity, even if their current physical consumption is only 1.5 TB.

This is overcommitment: logical capacity exceeds currently available physical capacity. It can be useful, but it creates risk. Guest writes, snapshots, clones, swap files, and storage-array thin provisioning can all consume additional space. If VMFS reaches full capacity, writes may fail and virtual machines can become unstable or stop.

Monitor both the VMFS datastore and the storage array's backing pool. Maintain alerts and an operational response for rapid growth. Related operations include inflating a thin disk and consolidating snapshots.

Expanding a VMFS Datastore

When supported, VMFS capacity can be expanded without powering off the virtual machines stored on it. The general workflow is:

1. Increase the backing LUN or storage device capacity on the array or storage platform.
2. Rescan storage adapters on the affected ESXi hosts.
3. Confirm that the expected device identity and new size are visible.
4. Expand the VMFS datastore using the vSphere Client or documented ESXi procedure.
5. Verify the new usable capacity and confirm that monitoring alerts remain appropriate.

Use the VMFS datastore creation and VMFS datastore expansion workflows. Expansion support depends on the vSphere version, partition layout, storage device, and array configuration.

esxcli storage core adapter rescan --all
esxcli storage filesystem list
esxcli storage core device list
esxcli storage core path list
vmkfstools -P /vmfs/volumes/<datastore-name>

• esxcli storage filesystem list lists mounted file systems and VMFS datastore information.
• esxcli storage core device list shows storage devices visible to the host.
• esxcli storage core path list helps review paths between ESXi and devices.
• esxcli storage core adapter rescan --all rescans storage adapters after presentation or sizing changes.
• vmkfstools -P displays information about a mounted datastore.

Raw Device Mapping

Raw Device Mapping (RDM) associates a virtual machine with a raw storage LUN through VMware-managed mapping metadata. The VM accesses the mapped LUN rather than using an ordinary VMDK that stores its data inside VMFS.

Consider RDM only after checking application requirements, guest clustering behavior, backup and replication tools, snapshot needs, migration options, and current VMware support. See Raw Device Mapping and adding a raw LUN.

Operational Safety

A datastore may contain many VMs and their dependent files. Deleting, formatting, resignaturing, detaching, or unmounting its backing device can affect every workload that uses it.

• Identify the datastore, backing device, device identifier, paths, and dependent VMs before making changes.
• Do not format or recreate a device because it appears empty or unavailable in one interface.
• Do not detach or unmount a datastore until workloads, templates, ISO references, snapshots, swap files, and management dependencies are checked.
• Use approved maintenance and change-control procedures.
• Confirm multipathing, host visibility, and array-side configuration before treating a datastore as shared.

Troubleshooting VMFS and Datastore Access

Datastore visible on one host but absent on another

• Likely causes: the LUN was not presented to every host; zoning, masking, iSCSI networking, or adapter configuration differs; the affected host has not rescanned; or a path/device is unhealthy.
• Investigation: compare device and path lists on each host, verify storage presentation and connectivity, rescan adapters, review path state, and confirm that all hosts see the same backing-device identity.

vMotion or HA cannot use another host

• Likely causes: the destination host lacks datastore access, the datastore is local rather than shared, or a non-storage requirement such as networking, licensing, CPU compatibility, or cluster configuration is unmet.
• Investigation: verify shared datastore accessibility on both hosts, check host and cluster compatibility, and read the task or event error for the specific failed prerequisite.

Thin-provisioned datastore is nearly full

• Likely causes: guest writes increased allocation, snapshots or delta files grew, several thin disks were overcommitted, or the array's thin-provisioned pool is also exhausted.
• Investigation: review free capacity and growth trends, identify large VMDKs and snapshots, check the array pool, and reclaim, migrate, expand, or otherwise restore safe headroom according to policy.

Datastore is inaccessible or degraded

• Likely causes: unavailable or intermittent paths; SAN, iSCSI, switch, HBA, cable, or array faults; a changed or removed backing device; or an unexpected storage identity condition.
• Investigation: inspect device and path status, review ESXi and array events, identify the backing LUN before taking action, and use documented recovery procedures for the platform version.

Exam-Relevant Notes

• VMFS is VMware's clustered file system; a datastore is the ESXi-visible logical container backed by a device or LUN.
• A VMFS datastore is not the same as its physical disk or LUN.
• The guest normally uses NTFS, ext4, XFS, or another native file system inside a VMDK; it does not use VMFS directly.
• Shared VMFS requires consistent presentation and visibility to every participating ESXi host.
• Shared storage supports common vMotion and HA designs, while DRS, Fault Tolerance, and other advanced features have additional requirements.
• Thin provisioning increases flexibility but introduces datastore overcommitment and capacity-exhaustion risk.
• Always validate version-specific limits rather than relying on historical VMFS-5 figures.
• Destructive datastore operations can affect every VM stored on that datastore.