Hubbry Logo
VMware VMFSVMware VMFSMain
Open search
VMware VMFS
Community hub
VMware VMFS
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
VMware VMFS
VMware VMFS
VMware VMFS
View on Wikipedia
from Wikipedia
VMFS
Developer(s)VMware, Inc.
Full nameVirtual Machine File System
Introducedwith ESX Server v1.x
Partition IDs0xfb (MBR)
Limits
Max volume size64 TB (VMFS5) [1]
Max file size62 TB [2][3]
Max no. of files~130,690 (VMFS5) [2]
Features
Transparent
compression		No
Transparent
encryption		No
Data deduplicationNo
Other
Supported
operating systems		VMware ESX

VMware VMFS (Virtual Machine File System) is VMware, Inc.'s clustered file system used by the company's flagship server virtualization suite, vSphere. It was developed to store virtual machine disk images, including snapshots. Multiple servers can read/write the same filesystem simultaneously while individual virtual machine files are locked. VMFS volumes can be logically "grown" (non-destructively increased in size) by spanning multiple VMFS volumes together.

Version history

[edit]

There are six (plus one for vSAN) versions of VMFS, corresponding with ESX/ESXi Server product releases.

  • VMFS0 can be reported by ESX Server v6.5 as a VMFS version when a datastore is unmounted from a cluster/host.
  • VMFS1 was used by ESX Server v1.x. It did not feature the cluster filesystem properties and was used only by a single server at a time. VMFS1 is a flat filesystem with no directory structure.
  • VMFS2 is used by ESX Server v2.x and (in a limited capacity) v3.x. VMFS2 is a flat filesystem with no directory structure.
  • VMFS3 is used by ESX Server v3.x and vSphere 4.x. Notably, it introduces directory structure in the filesystem.
  • VMFS5 is used by vSphere 5.x. Notably, it raises the extent limit to 64 TB and the file size limit to 62 TB,[2] though vSphere versions earlier than 5.5 are limited to VMDKs smaller than 2 TB.[4]
  • VMFS6 is used by vSphere 6.5. It supports 512 emulation (512e) mode drives.[5]
  • VMFS-L is the underlying file system for VSAN-1.0. Leaf level VSAN objects reside directly on VMFS-L volumes that are composed from server side direct attached storage (DAS). File system format is optimized for DAS. Optimizations include aggressive caching with for the DAS use case, a stripped lock down lock manager and faster formats.

Features

[edit]
  • Allows access by multiple ESXi servers at the same time by implementing per-file locking. SCSI reservations are only implemented when logical unit number (LUN) metadata is updated (e.g. file name change, file size change, etc.)
  • Add or delete an ESXi server from a VMware VMFS volume without disrupting other ESXi servers.
  • With ESX/ESXi4, VMFS volumes can also be expanded using LUN expansion.
  • Optimize virtual machine I/O with adjustable volume, disk, file and block sizes.
  • Recover virtual machines faster and more reliably in the event of server failure with Distributed Journaling.
  • While present in previous versions automatic unmap was added to VMFS 6 allowing for automatic space reclamation requests which previously were manually actioned.

Limitations

[edit]
  • Can be shared with up to 64 ESXi Servers.[6]
  • Maximum filesystem size is 50 TB as of VMFS3, and 62 TB as of VMFS5.[6]
  • Maximum LUN size of 2 TB as of VMFS3[6] and 64 TB as of VMFS5.[1]
  • In VMFS3 and VMFS5 prior to vSphere 5.1, the maximum number of hosts which can share a read-only file is 8. This affects the scalability of linked clones sharing the same base image. In vSphere 5.1, this limit is increased to 32 with the introduction of a new locking mechanism.[7][8]
  • VMFS3 limits files to 262,144 (218) blocks, which translates to 256 GB for 1 MB block sizes (the default) up to 2 TB for 8 MB block sizes.[6]
  • VMFS5 uses 1 MB blocks throughout (with block suballocation for small files), and has a file size limit of 62 TB,[2] though the VMDK size is restricted to 2 TB - 512 B in ESXi versions earlier than 5.5[4] due to a limitation in the version of SCSI emulated.
  • There is also a limit of approximately 30,720 files (using MBR) on a single VMFS3 datastore. This has been raised to 130,690 files (using GPT) on VMFS5 [4]

Open-source implementations

[edit]

fluidOps Command Line Tool

[edit]

A Java open source VMFS driver[9] enables read-only access to files and folders on partitions formatted with the Virtual Machine File System (VMFS) is developed and maintained by Fluid Operations. It allows features like offloaded backups of virtual machines hosted on VMware ESXi hosts up to VMFSv3.

glandium VFS FUSE Mount

[edit]

vmfs-tools supports more VMFS features and read only VMFS mounts through the standard Linux VFS and the FUSE framework. Developed by Christophe Fillot and Mike Hommey and available as source code download at the glandium.org vmfs-tools page[10] or the Debian vmfs-tools[11] and Ubuntu vmfs-tools[12] packages.

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

VMware VMFS

View on Grokipedia
from Grokipedia
VMware VMFS (Virtual Machine File System) is a high-performance developed by for its vSphere virtualization platform, optimized for storing files such as virtual disks, configuration files, and snapshots on shared block storage devices like LUNs. It enables multiple ESXi hosts to concurrently read from and write to the same datastore, supporting for large virtual environments through distributed locking and metadata management that ensures and prevents corruption. VMFS encapsulates the entire state of a within a single directory, simplifying provisioning, migration, and management in clustered setups. Introduced with early versions of VMware ESX, VMFS has evolved through several iterations to address growing demands for storage efficiency and performance in virtualized infrastructures. VMFS3, released around 2007, supported extents up to 2 TB each, allowing volumes up to 64 TB across 32 extents, but required manual spanning for larger capacities. VMFS5, introduced in vSphere 5.0 in 2011, improved this by enabling single-extent volumes up to 64 TB and adding support for hardware acceleration features like ATS (Atomic Test and Set). The current version, VMFS6, launched with vSphere 6.5 in 2017, enhances scalability with support for up to 32 extents per volume (up to 64 TB per extent in supported configurations), faster file creation for environments with millions of files, space reclamation for thin-provisioned storage, and unified 1 MB block allocation for large files and 64 KB sub-block allocation for small files and directories to boost I/O performance. As of vSphere 9.0 (2025), VMFS6 remains the latest version, compatible with all modern vSphere releases and designed to support large-scale enterprise storage, with individual datastores up to 64 TB. Key capabilities of VMFS include seamless integration with vSphere features such as vMotion for live VM migration, (HA) for , Distributed Resource Scheduler (DRS) for load balancing, and Storage vMotion for non-disruptive data mobility. It supports dynamic datastore expansion without downtime, automatic space reclamation on thin-provisioned LUNs via UNMAP, and up to 32 hosts sharing a single volume, making it ideal for high-availability clusters. Unlike traditional file systems, VMFS uses a distributed where metadata updates are coordinated across hosts, reducing contention and enabling efficient concurrent access to virtual disks in I/O-intensive workloads. These attributes position VMFS as a foundational component for VMware's software-defined storage , though it is typically used alongside NFS or vSAN for hybrid environments.

Introduction

Definition and Purpose

VMFS (Virtual Machine File System) is a proprietary, high-performance cluster file system developed by specifically for storing files on ESXi hosts. It is optimized to manage large files such as virtual machine disk images (VMDKs), snapshots, configuration files, and swap files, providing an efficient access layer for virtual machines to read and write data on underlying block storage devices. The primary purpose of VMFS is to enable multiple ESXi hosts in a vSphere cluster to access shared datastores concurrently and safely, without requiring or manual coordination, thereby supporting scalable workloads in enterprise environments. This distributed architecture allows for seamless operations like (vMotion) and () across hosts, ensuring that virtual machines can run continuously even as storage is shared among servers. VMFS was introduced in alongside the initial release of ESX Server 1.0, starting as a simple flat for single-host use and evolving into a robust to meet the demands of multi-host . Over time, its versions have advanced to incorporate enhanced clustering capabilities, though core principles of shared access remain central. Key benefits of VMFS include built-in through atomic updates and locking mechanisms that prevent during concurrent operations, to handle petabyte-scale enterprise storage pools, and deep integration with the for optimized I/O performance and resource management in virtualized data centers.

High-Level Architecture

VMFS functions as a hybrid volume manager and tailored for environments, enabling multiple ESXi hosts to share block storage resources efficiently while maintaining and performance. It operates on top of block devices such as Logical Unit Numbers (LUNs) presented via Storage Area Networks (SAN), iSCSI, or (FCoE), abstracting these into logical datastores that store files, including virtual disks (.vmdk), configuration files (.vmx), and snapshots. This architecture assumes familiarity with fundamentals, positioning VMFS as an optimized layer for high-concurrency access in virtualized infrastructures. The on-disk layout of VMFS centers on a structured metadata framework beginning with a superblock in the volume header, which encapsulates critical information like the volume's (UUID), VMFS version, block size, capacity, and pointers to subsequent metadata areas. File allocation and mapping rely on a (FAT) combined with pointer blocks, which organize data into 1 MB blocks (with sub-block support for smaller files in VMFS5 and VMFS6) and direct hosts to file extents across the storage. This design facilitates scalable , where files are represented as sparse or flat structures without contiguous allocation requirements, prioritizing rapid access over traditional rigidity. Metadata, including directories and file descriptors, resides in dedicated .sf files at the volume , ensuring quick recovery and consistency checks during mount operations. To support shared access without a centralized lock manager, VMFS implements distributed on-disk locking through atomic test-and-set (ATS) primitives on metadata blocks, allowing granular control over concurrent operations from multiple hosts. This mechanism, hardware-accelerated on compliant storage arrays via T10 VAAI, prevents conflicts by locking specific sectors rather than entire devices, with fallbacks to reservations for legacy setups. Examples include lock indicators on VM files (e.g., .lck extensions) that signal active use, ensuring no duplicate powering-on of virtual machines across the cluster. Complementing this, a distributed journaling records metadata modifications in redo logs, buffering uncommitted changes for atomic application and enabling resilient crash recovery by replaying logs to restore consistency without full scans. VMFS enhances scalability by supporting extents, where a single volume can aggregate multiple LUNs as additional storage partitions, allowing non-disruptive expansion up to 64 TB in modern versions. Each extent represents a contiguous block device slice, with the primary extent housing core metadata; all LUNs must be visible to participating hosts for seamless operation in SAN topologies. This extent-based approach decouples volume capacity from individual device limits, optimizing resource utilization in enterprise storage arrays.

Development History

Early Versions (VMFS1-3)

VMFS1, introduced with ESX Server 1.x in 2001, served as a basic designed exclusively for single-host environments. It operated as a flat without support for directories, limiting its functionality to simple storage of files such as virtual disks (.vmdk) on logical unit numbers (LUNs). This version lacked clustering capabilities, preventing concurrent access by multiple ESX servers and requiring manual configuration for any host changes. VMFS2, released alongside ESX Server 2.x in 2002 and carried over into early ESX 3.x, retained the flat file structure of its predecessor but introduced foundational support for multi-host sharing. This allowed multiple ESX servers to access the same VMFS volume, albeit with manual mounting procedures and no automated discovery. Per-file locking mechanisms were initially implemented to enable safe concurrent access to individual files, laying the groundwork for features like VMotion, which debuted in 2003 with VirtualCenter 1.0 and relied on shared VMFS storage for live migration. However, VMFS2 volumes were constrained to a maximum size of 2 terabytes per LUN, reflecting the era's storage limitations. VMFS3, launched with ESX Server 3.x in 2006 and extended through vSphere 4.x, marked a significant evolution by introducing a hierarchical , enabling organized management of files within volumes. It adopted (MBR) partitioning while supporting up to 2 terabyte LUNs and allowing volumes to span multiple extents for a maximum size of 64 terabytes. Concurrent access was enhanced to support up to 32 hosts through refined on-disk locking, facilitating more robust clustering and seamless integration with VMotion for live migrations across ESXi hosts. These advancements shifted VMFS from a rudimentary single-host system to a viable foundation for shared environments, though it still required manual extent management for expansion beyond single LUN capacities.

Modern Versions (VMFS5-6)

VMFS5, introduced with vSphere 5.0 in , represented a major evolution in scalability for the Virtual Machine File System by transitioning to a GPT-based partition scheme from the MBR used in prior versions, allowing for much larger datastores without the 2 TB limitation of VMFS3. This version supports a maximum or LUN size of 64 TB and a maximum of 62 TB, enabling administrators to consolidate more virtual machines on fewer, larger storage units. Additionally, VMFS5 accommodates up to 32 ESXi hosts sharing a datastore and introduces deterministic extents, which provide more predictable and efficient spanning across multiple LUNs for expansion up to 32 extents. Building on these foundations, VMFS6 debuted with vSphere 6.5 in , focusing on performance optimizations for modern hardware. It offers native support for 512e (512-byte emulation) and 4Kn (4 KB native) sector formats on advanced drives, ensuring better alignment and I/O efficiency without emulation overhead. Key enhancements include automatic space reclamation via asynchronous UNMAP operations, which periodically release freed blocks from thin-provisioned virtual disks to optimize storage utilization, and accelerated metadata updates that reduce locking contention and speed up operations like file creation and power-on. These changes particularly benefit SSD-based environments by improving overall I/O handling and reducing latency for metadata-intensive tasks. Compared to VMFS3, both VMFS5 and VMFS6 deliver substantial scalability gains, such as support for up to 130,000 files per volume versus the 30,000 limit in VMFS3, allowing denser deployments. Upgrade paths emphasize minimal disruption: VMFS3 volumes can be upgraded in-place to VMFS5 directly through the vSphere Client or ESXCLI commands without requiring or for running virtual machines, while transitioning from VMFS5 to VMFS6 involves evacuating virtual machines via Storage vMotion and recreating the datastore to leverage the new features. These advancements addressed earlier constraints in file counts and I/O performance, paving the way for larger-scale vSphere environments.

Current Status (as of 2025)

As of 2025, VMFS remains a cornerstone of shared storage in vSphere environments, with full support for versions 5 and 6 integrated into ESXi 8.x and vSphere 9.0 releases. VMFS3 is unsupported in ESXi 7.0 and later versions, requiring migration to VMFS5 or VMFS6 for compatibility with modern vSphere releases. These platforms enable seamless deployment and management of VMFS datastores alongside modern features, ensuring compatibility for existing workloads without requiring immediate migration. No announcement of a VMFS7 version has been made by ('s parent company), indicating a focus on refining existing iterations rather than introducing a new major release. The 64TB volume size limit for VMFS5 and VMFS6 persists despite advancements in storage hardware, such as larger NVMe drives, primarily to maintain with legacy 32-bit metadata structures and avoid the need for a disruptive format overhaul. This cap, while sufficient for many traditional deployments, underscores ongoing design trade-offs prioritizing stability over expansion in on-premises setups. VMFS continues to integrate effectively with contemporary storage technologies, including NVMe over Fabrics and like vSAN, allowing ESXi hosts to utilize high-performance SSDs for local or external datastores. However, for workloads demanding granular storage policies and array-level optimizations—such as those in cloud-native or AI-driven environments—VMware documentation recommends transitioning to vSphere Virtual Volumes (vVOLs) to leverage protocol-specific features like NVMe/TCP. No end-of-life (EOL) date has been declared for VMFS, affirming its enduring role in hybrid and private cloud architectures, though broader strategies show a gradual pivot toward container-native storage solutions in offerings like VMware Cloud Foundation. This shift emphasizes software-defined storage like vSAN for scalable, policy-driven management in Kubernetes-integrated environments, potentially reducing reliance on block-based file systems like VMFS for new deployments. Recent ESXi updates from 2023 to 2025 have included minor patches enhancing VMFS reliability, such as security fixes for vulnerabilities in the storage stack and improved compatibility with 512e/4Kn advanced format drives, ensuring robust operation on modern hardware without major architectural changes.

Core Technical Features

Clustering and Locking Mechanisms

VMware VMFS enables shared access to datastores across multiple ESXi hosts in a vSphere cluster through distributed locking mechanisms that coordinate concurrent operations and prevent . These mechanisms rely on on-disk metadata structures rather than network-based protocols, allowing hosts to perform atomic updates directly on the storage device. For instance, when a host attempts to power on a , it must acquire an exclusive lock on key files such as the .vmx configuration and .vmdk disk files to ensure no other host can modify them simultaneously. This locking is implemented via VMFS metadata on the volume, using techniques like SCSI-2 reservations for legacy compatibility and the more efficient Atomic Test-and-Set (ATS) primitive in VMFS5 and later versions. A critical component of this coordination is the heartbeat mechanism, which allows ESXi hosts to claim and maintain access to a VMFS volume while detecting host failures. Each host acquires a dedicated heartbeat slot in the volume's Heartbeat Region—a 1-sector on-disk area—and updates it periodically every 3 seconds using ATS operations to indicate liveness. The heartbeat includes the host's UUID and a ; if a slot is not refreshed within the 16-second lease timeout, the host is deemed failed, enabling other hosts to reclaim locks and resources. This supports rapid failure detection and recovery in clustered environments, with associated timeouts including an 8-second I/O timeout for heartbeat updates. By using SCSI reservations only when ATS is unavailable, VMFS minimizes contention during these operations. VMFS's locking design scales to support up to 32 hosts simultaneously accessing a single datastore in VMFS5 and later versions. Lock contention is reduced through fine-grained locking at the sector level (typically 512 bytes for metadata locks), allowing multiple hosts to operate on different files or regions without blocking. This ensures that operations like file creation or metadata updates affect only small portions of the volume, facilitating high concurrency in large clusters. Integration with vSphere features such as Storage Distributed Resource Scheduler (Storage DRS) leverages these mechanisms to automatically balance workloads across datastores by migrating files via Storage vMotion, relying on the robust multi-host locking to maintain during load balancing. In comparison to NFS datastores, VMFS's on-disk locking avoids dependency on network protocols for metadata operations, providing more reliable coordination in environments with potential network latency or failures. While NFS employs proprietary .lck files and network-mediated locks for file access control, VMFS handles all locking atomically at the storage layer, reducing overhead for common tasks like virtual machine registration and ensuring consistent behavior even under heavy multi-host load.

Volume Management and Expansion

VMFS employs an extent-based to manage storage volumes as logical aggregates of one or more logical unit numbers (LUNs), enabling a single datastore to span multiple physical storage devices while presenting them as a unified entity to the vSphere environment. This spanning capability allows VMFS to concatenate extents without striping I/O across them, providing flexibility in provisioning storage from diverse arrays. In VMFS5 and subsequent versions, datastores can incorporate up to 32 extents, with each extent supporting sizes greater than 2 TB and reaching a maximum of 64 TB in VMFS6. Expansion of VMFS volumes occurs online without necessitating downtime for hosted virtual machines, supporting dynamic growth to accommodate increasing demands. Since ESXi 4.0, the VMFS Volume Grow feature facilitates resizing an underlying LUN directly at the storage array level, after which ESXi hosts perform a storage rescan to incorporate the additional capacity into the existing extent. Alternatively, administrators can add new extents by presenting additional LUNs and using tools such as the vSphere Client's "Increase Datastore Capacity" wizard or the vmkfstools CLI command, ensuring the datastore remains accessible during the process. A post-expansion rescan across all cluster hosts is required to propagate the changes. Resizing limits for VMFS extents differ across versions to address evolving storage needs. VMFS3 restricts each extent to 2 TB, often requiring multiple extents for larger volumes and relying on MBR partitioning, which limits compatibility with drives exceeding that size. In contrast, VMFS5 and VMFS6 extend support to 64 TB per extent through GPT partitioning, eliminating the need for spanning in most scenarios and enabling efficient handling of massive datasets. The maximum capacity for a single VMFS5 or VMFS6 datastore remains 64 TB, though practical configurations may vary based on hardware constraints. VMFS metadata, essential for tracking file locations, permissions, and structures, typically accounts for 0.5-2% overhead of the total capacity, influenced by LUN size and file count. To minimize space inefficiency for small files and directories, VMFS implements sub-block allocation, utilizing subdivisions of the default 1 MB file block to store content smaller than a full block, thereby reducing fragmentation and overhead. Effective volume management in VMFS emphasizes alignment of extents and partitions to the storage array's native block size, such as 64 KB offsets, to optimize I/O throughput and prevent misalignment penalties. Administrators should prioritize single large LUNs as extents for streamlined operations, reserving multi-extent configurations for scenarios requiring workload isolation, and always verify storage rescans post-expansion to maintain consistency.

Creating a VMFS Datastore

To create a new VMFS6 datastore on a blank SSD, administrators use the ESXi Host Client by navigating to Storage > Devices, selecting the target device, initiating the New Datastore action, selecting VMFS6 as the filesystem type, assigning a name to the datastore, and allocating the full capacity of the device to the partition. Upon completion, the process formats and mounts the empty datastore, making it available for virtual machine storage in the vSphere environment.

Advanced Capabilities

Space Reclamation and Performance Optimizations

VMFS6 introduces automatic space reclamation through UNMAP operations, which periodically issue TRIM-like commands to identify and release blocks associated with deleted disk (VMDK) files on thin-provisioned storage arrays. This asynchronous process operates at a controlled rate to prevent performance impacts on the underlying storage, typically completing reclamation within 12 to 24 hours after space becomes available, thereby optimizing without manual intervention. To minimize internal fragmentation and wasted space for small files such as configuration files (.vmx), VMFS employs sub-block allocation, utilizing 64 KB units for files under 1 MB in size. This approach, an evolution from the 8 KB sub-blocks in VMFS5, dynamically allocates resources—starting with 16,384 sub-blocks (1 GB total)—to back metadata and small objects efficiently, reducing overhead compared to assigning full 1 MB file blocks. Input/output (I/O) performance in clustered environments benefits from Atomic Test and Set (ATS) mechanisms, a VAAI primitive that enables lock-free metadata updates by replacing traditional reservations with hardware-accelerated atomic operations. This scalable locking reduces contention and latency during concurrent access, particularly for operations like file creation or extension in multi-host setups, allowing up to 64 hosts to perform metadata updates without queuing delays. vSphere supports host-side caching optimizations compatible with VMFS6 datastores, leveraging SSDs as a read cache for datastore contents, including metadata, to accelerate access patterns in hybrid or all-flash configurations. This SSD-aware feature allocates a configurable portion of local flash storage (e.g., via PCIe or ) for caching frequently accessed blocks, improving latency for metadata-intensive tasks while prioritizing larger I/O sizes for better SSD endurance. Optimized distributed journaling in VMFS6 enhances metadata resilience and recovery speed by changes across multiple zones, enabling quicker crash recovery and reduced during host failures or cluster events compared to prior versions. This journaling supports concurrent transactions per host, facilitating faster volume mounting and operational continuity in large-scale vSphere deployments.

Integration with vSphere Features

VMFS integrates seamlessly with vSphere's features, enabling efficient workload mobility across clustered environments. vMotion allows the of running virtual machines (VMs) between ESXi hosts sharing the same VMFS datastore, relying on VMFS's distributed locking mechanisms—such as Atomic Test-and-Set (ATS) primitives via vStorage APIs for Array Integration (VAAI)—to ensure safe concurrent access and prevent during the transfer of VM and state. This locking ensures that only one host can write to VM files at a time, supporting zero-downtime migrations without requiring host downtime. Similarly, Storage vMotion facilitates the non-disruptive relocation of VM files between VMFS datastores or even across different storage types, leveraging VAAI offloads like Extended Copy to accelerate data movement and reduce host CPU overhead. For data protection and , VMFS supports vSphere's snapshot and capabilities through its structure. Snapshots create point-in-time copies of VMs by generating delta VMDK files alongside the base virtual disks on the VMFS volume, preserving the original disk state while redirecting new writes to the delta for consistent backups and recovery operations. These delta disks, often in VMFSSPARSE format on VMFS, enable efficient space usage and quick snapshot creation without full . In scenarios, VMFS provides the shared storage foundation required for continuous VM availability, using multi-writer mode on dedicated redo log disks to allow synchronized primary and secondary VMs to log changes atomically across hosts, ensuring zero data loss during hardware failures. VMFS also maintains compatibility with vSphere's software-defined storage options, such as vSAN, allowing hybrid configurations in (HCI) setups. While vSAN operates on an object-based , VMFS serves as a block-based datastore that can coexist within the same vSphere cluster, supporting Storage vMotion migrations between VMFS and vSAN datastores through object-to-block translation handled by vCenter Server. This integration enables administrators to leverage VMFS for traditional SAN/NAS backends alongside vSAN's local disk pooling, facilitating gradual transitions or mixed-storage environments without disrupting VM operations. VMFS6 capabilities remain fully supported in vSphere 9.0 as of 2025. Automation and management of VMFS are enhanced through vSphere APIs, providing programmatic control over datastore lifecycle. The vSphere Web Services SDK and PowerCLI enable tasks such as creating, mounting, resizing, and querying VMFS datastores via methods like DatastoreSystem.CreateVmfsDatastore, allowing integration with orchestration tools for dynamic provisioning and monitoring. For instance, PowerCLI cmdlets like New-Datastore support VMFS volume setup on LUNs, streamlining administrative workflows in large-scale deployments. Security features in vSphere extend to VMFS through native encryption support, protecting data at rest. vSphere Virtual Machine Encryption secures VM files—including VMDKs and configuration—stored on VMFS volumes using AES-256 encryption keys managed by a Key Management Server (KMS), ensuring confidentiality even if physical storage is compromised. This integration applies transparently to VMFS without requiring filesystem modifications, with vCenter handling key rotation and policy enforcement across encrypted datastores.

Limitations

Scalability Constraints

VMFS imposes a strict limit of 64 ESXi hosts that can simultaneously access a single volume, a constraint established with VMFS5 and unchanged in subsequent versions including VMFS6. This cap ensures reliable on-disk locking for shared files but restricts VMFS's applicability in very large clusters, where exceeding this threshold requires partitioning workloads across multiple volumes. The file system also limits the total number of files per volume, with VMFS3 supporting approximately 30,720 files and VMFS5/VMFS6 increasing this to around 130,690 files. In dense environments, this can result in "file explosion," where the proliferation of small files—such as those from snapshots, logs, and temporary —quickly approaches or exceeds the limit, complicating management and potentially degrading performance due to metadata overhead. Beyond hard limits, operational scalability is affected by cluster overhead, particularly lock contention, which escalates with more than 32 hosts sharing a datastore. This contention arises from frequent coordination of metadata updates across hosts, increasing latency for I/O operations and administrative tasks; best practices recommend distributing workloads across multiple datastores to maintain in larger configurations. To address these constraints in deployments scaling beyond 64 hosts, suggests alternatives like vVols, which provision storage at the level for finer-grained , or NFS datastores, which support broader host sharing without VMFS's per-volume host restrictions. In practice, VMFS performs reliably for mid-sized clusters but encounters strain in mega-scale environments hosting 1000 or more VMs, where the combined effects of host limits, file counts, and locking overhead necessitate careful datastore segmentation.

Compatibility and Size Limits

VMware VMFS imposes specific hardware and capacity restrictions that have evolved across versions but remain constrained by design choices. For VMFS5 and VMFS6, the maximum supported volume size is 64 TB, while individual files, such as disks (VMDKs), are limited to approximately 62 TB due to metadata overhead. In contrast, VMFS3 restricts logical unit numbers (LUNs) to 2 TB extents, necessitating spanning multiple LUNs to achieve larger volumes up to 64 TB. Drive compatibility varies significantly by VMFS version, particularly with advanced sector formats. VMFS6, introduced in vSphere 6.5, provides native support for 512-byte emulation (512e) drives, eliminating the need for additional emulation layers and improving performance on modern storage arrays. Starting with vSphere 6.7, VMFS6 extends support to 4Kn (4 KB native) drives for direct-attached SAS and HDDs, though bootable configurations require firmware and no raw device mapping (RDM) is available for 4Kn. Older versions, such as VMFS5 and earlier, lack native support for these formats; 512e drives may function with emulation but risk performance degradation or instability, and 4Kn drives are unsupported without hardware-level translation. Partitioning schemes further define compatibility boundaries. VMFS3 relies exclusively on the (MBR) format, which caps partitions at under 2 TB and introduces risks such as boot sector corruption when attempting to exceed this limit without proper conversion. VMFS5 and later versions default to (GPT) for new datastores, enabling volumes larger than 2 TB; however, datastores upgraded from VMFS3 retain the MBR scheme unless reformatted, potentially exposing them to the same legacy limitations and recovery challenges during failures. As of 2025, the 64 TB volume limit for VMFS5 and VMFS6 persists unchanged, rooted in legacy metadata structures that, while allowing technically larger creations, risk and are unsupported by . This cap endures despite hardware advancements supporting petabyte-scale storage, as exceeding it invalidates official validation and support. Migration and processes preserve these limits, complicating transitions to larger capacities. Direct in-place upgrades from VMFS5 to VMFS6 are not possible; instead, administrators must create a new VMFS6 volume and migrate virtual machines, which retains the 64 TB ceiling unless the source datastore is reformatted entirely. Similarly, expanding beyond 64 TB requires a full reformat and data relocation, as no automated path exists to leverage greater hardware potential without violating compatibility boundaries.

Open-Source Implementations

fluidOps Command Line Tool

The fluidOps Command Line Tool is an open-source Java-based (CLI) developed by fluid Operations AG for read-only access to legacy VMFS datastores, specifically VMFS3 and earlier versions, on non-ESXi systems such as and Windows hosts. It enables mounting and extraction of data from VMFS volumes outside environments, making it suitable for scenarios like from failed hardware or offline analysis without a running ESXi . The tool operates by parsing the VMFS file system structure directly, supporting both local device access and remote connections via SSH/SFTP for distributed environments. Key capabilities include listing directory contents, reading VMDK virtual disk files, and copying entire virtual machines or individual files to external storage. It supports passthrough for access to physical block devices (e.g., /dev/sda5 on or \\.\PhysicalDrive3 on Windows) and can handle disk image files in certain configurations. For instance, the info command displays volume metadata, such as partition layout and details, while the webdav mode launches an embedded HTTP server on port 50080 for browser-based browsing and file downloads via . On , it integrates with standard tools like dd or scp for streamlined data extraction, facilitating forensic workflows. Usage follows the syntax java -jar fvmfs.jar <device> <command> [options], where commands like ls enumerate files and get retrieves specific items. As a read-only tool, it does not permit write operations, volume modifications, or snapshot handling, limiting its use to extraction tasks. It provides no support for VMFS5 or VMFS6 due to structural differences in those formats. The project received its last significant update in (version 0.9.8.18, dated January 25, 2010), after which maintenance ceased. The developing company, fluid Operations AG, was acquired by in 2018. The tool's source code, binaries, and documentation are hosted in the archived Code repository under the GNU General Public License version 3, emphasizing its role in forensics and recovery for legacy deployments.

Glandium VFS FUSE Mount

The Glandium VFS FUSE Mount refers to the FUSE-based component of the vmfs-tools project, a set of open-source utilities written in C that enable read-only mounting of VMFS file systems up to version 5 on hosts. Developed to provide seamless interoperability, it integrates VMFS volumes into the standard Virtual File System (VFS), allowing non- environments to access virtual machine files without proprietary tools. Key features include the vmfs-fuse program, which mounts VMFS partitions—either from block devices or disk images—at a user-specified directory, such as /mnt/vmfs, for straightforward navigation and file operations using familiar commands like ls, cp, and tar. The tool supports advanced VMFS structures, including multi-extent volumes, and parses metadata to present files in a hierarchical view compatible with standard utilities. This approach contrasts with pure command-line alternatives, such as the fluidOps tool, by offering persistent mount points that simplify integration into scripts and workflows. Initiated in 2009 by developers Mike Hommey (known as glandium) and Christophe Fillot, the project built upon earlier VMFS parsing code from fluidOps and saw iterative enhancements, including limited VMFS5 support introduced in version 0.2.5. Development activity peaked through 2012 with official releases but continued via commits until around 2015, after which the repository stabilized; community forks and integrations, such as in , have sustained its relevance for scenarios. Licensed under the GNU GPL v2 or later, vmfs-tools is readily available as a package in and repositories, requiring dependencies like libfuse for FUSE functionality. While advantageous for its native emulation and efficient metadata handling—which enables tasks like bulk extraction without custom parsing—the FUSE mount operates strictly in read-only mode and is explicitly not recommended for production use due to its experimental nature. Potential issues arise with large volumes or files over 256 GB on VMFS5, where errors or incomplete support may occur, limiting reliability for extensive datasets. For VMFS6, community forks such as vmfs6-tools extend support with read-only FUSE mounting on , available in recent Debian and packages as of 2025.

References

  1. https://www.vmware.com/docs/vmware-vsphere-vmfs
  2. https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.storage.doc/GUID-5EE84941-366D-4D37-8B7B-767D08928888.html
  3. https://www.vmware.com/techpapers/2007/performance-characteristics-of-vmfs-and-rdm-1019.html
  4. https://www.nakivo.com/blog/all-you-need-to-know-about-vmware-vmfs/
  5. https://williamlam.com/2023/04/esx-server-1-0-trip-down-memory-lane.html
  6. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/vsphere-storage-7-0/working-with-datastores-in-vsphere-storage-environment/vsphere-vmfs-datastore-concepts-and-operations.html
  7. https://vmfsrecover.com/articles/how-vmfs-works-inside-vmwares-file-system-architecture
  8. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/6-7/vsphere-storage-6-7/working-with-datastores-in-vsphere-storage-environment/vsphere-vmfs-datastore-concepts-and-operations/vmfs-metadata-updates.html
  9. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage-8-0/working-with-datastores-in-vsphere-storage-environment/managing-vsphere-vmfs-datastores/vsphere-vmfs-locking-mechanisms.html
  10. https://www.oreilly.com/library/view/storage-implementation-in/9780132842228/ch12.html
  11. https://virtualizationreview.com/articles/2016/09/14/evolution-of-vmware-vmotion.aspx
  12. https://knowledge.broadcom.com/external/article/323144/using-partedutil-command-line-disk-parti.html
  13. https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-esxi-65u3-release-notes.html
  14. https://www.vmware.com/docs/whats-new-vsphere65-perf
  15. https://www.boche.net/blog/index.php/2011/07/21/vmfs-5-vmfs-3-whats-the-deal/
  16. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/6-7/vsphere-storage-6-7/working-with-datastores-in-vsphere-storage-environment/vsphere-vmfs-datastore-concepts-and-operations/versions-of-vmfs-datastores.html
  17. https://blogs.vmware.com/cloud-foundation/2025/06/23/vsphere-in-vcf-9-0-whats-new/
  18. https://knowledge.broadcom.com/external/article/410951/vmfs-datastore-maximum-supported-capacit.html
  19. https://blogs.vmware.com/cloud-foundation/2025/06/19/vsphere-and-vcf-9-core-storage-whats-new/
  20. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage-8-0/about-vmware-nvme-storage/requirements-for-vmware-nvme-storage.html
  21. https://www.vmware.com/docs/private-cloud-outlook-2025
  22. https://blogs.vmware.com/cloud-foundation/2025/06/17/announcing-availability-of-vsan-9-0/
  23. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/esxi-update-and-patch-release-notes/vsphere-esxi-80u3g-release-notes.html
  24. https://kb.vmware.com/s/article/10051
  25. https://kb.vmware.com/s/article/52879
  26. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/increasing-vmfs-datastores.html
  27. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage-8-0/working-with-datastores-in-vsphere-storage-environment/managing-vsphere-vmfs-datastores/increase-capacity-of-vsphere-vmfs-datastore.html
  28. https://knowledge.broadcom.com/external/article/394370/faq-total-usable-capacity-in-vmfs6.html
  29. https://www.vmware.com/docs/vsphere-esxi-vcenter-server-70u3-performance-best-practices
  30. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/vsphere-storage-7-0/working-with-datastores-in-vsphere-storage-environment/creating-vsphere-datastores/create-a-vsphere-vmfs-datastore.html
  31. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage-8-0/storage-provisioning-and-space-reclamation-in-vsphere/storage-space-reclamation-in-vsphere/space-recalmation-on-vsphere-vmfs-datastores.html
  32. https://cormachogan.com/2017/08/17/change-sub-blocks-vmfs-6/
  33. https://www.vmware.com/docs/vsphere-esxi-vcenter-server-80-performance-best-practices
  34. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage-8-0/using-flash-devices-with-esxi-hosts/configure-host-cache-with-vmfs-datastore-in-vsphere-environment.html
  35. https://kb.vmware.com/kb/1021976
  36. https://kb.vmware.com/kb/1015180
  37. https://kb.vmware.com/kb/1034165
  38. https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vmware-vsan-703-release-notes.html
  39. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-0.html
  40. https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-apis-sdks-getting-started/GUID-0F4F3274-DBD1-49A5-B0EE-1E021AFF46D7.html
  41. https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-6A952214-0E5E-4CCF-9D2A-90948FF643EC.html
  42. https://configmax.broadcom.com/
  43. https://www.bdrshield.com/blog/difference-vmware-vmfs-nfs-datastores/
  44. https://deinoscloud.wordpress.com/2010/07/26/understanding-vmfs-block-size-and-file-size/
  45. https://deinoscloud.wordpress.com/2011/02/27/vmfs-and-the-distributed-lock-management/
  46. https://knowledge.broadcom.com/external/article/327012/faq-support-statement-for-512e-and-4k-na.html
  47. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage-8-0/working-with-datastores-in-vsphere-storage-environment/vsphere-vmfs-datastore-concepts-and-operations.html
  48. https://code.google.com/archive/p/vmfs
  49. https://ryanbelanger.com/?p=353
  50. https://petri.com/access-vmfs-volumes-without-vmware-host/
  51. https://www.veritas.com/news-releases/2018-03-27-veritas-acquires-fluidops
  52. https://glandium.org/projects/vmfs-tools/
  53. https://glandium.org/blog/?p=347
  54. https://glandium.org/blog/?p=2539
  55. https://github.com/glandium/vmfs-tools
  56. https://github.com/glandium/vmfs-tools/issues/12
  57. https://superuser.com/questions/480356/cannot-mount-vmfs-version-5-on-linux
  58. https://packages.debian.org/sid/vmfs6-tools
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.