VMware ESXi and vSphere Cluster Management
Increase the Size of a VMFS Datastore in VMware vSphere
Learn how to expand a VMware VMFS datastore by enlarging its LUN or adding an extent, including planning, vSphere workflow, limits, verification, and troubleshooting.
A VMware vSphere datastore can run short of space because it was initially undersized, virtual machine disks grew unexpectedly, snapshots accumulated, or new virtual machines were added. VMFS datastore capacity can normally be increased online, so virtual machines do not need to be powered off for the capacity operation itself. Follow your organization's change-control and storage-maintenance procedures.
VMFS growth is one-way through the normal expansion workflow: you can expand a datastore, but you cannot use that workflow to reduce or shrink it. If capacity must later be reclaimed, plan a migration to another datastore or a replacement storage design.
Key VMFS Storage Terms
- VMFS: VMware Virtual Machine File System, the clustered file system used by ESXi hosts for shared datastores.
- Datastore: A vSphere storage container that holds virtual machine configuration files, virtual disks, snapshots, ISO files, and other virtual machine data.
- LUN: A logical storage device provisioned by a storage array and presented to ESXi.
- Extent: A partition on a LUN that contributes storage capacity to a VMFS datastore. A datastore may use one extent or multiple extents.
- Datastore expansion: Growing an existing VMFS extent into additional contiguous capacity on its current backing device.
- Add extent: Joining a partition from another compatible LUN to an existing VMFS datastore.
- Contiguous free space: Unallocated capacity immediately following the current VMFS extent on the same device. This layout is required for in-place expansion.
- Storage rescan: An ESXi discovery operation that detects changed LUN sizes, paths, and newly presented storage devices.
- Multipathing: The use of multiple storage paths between ESXi and a LUN for resiliency and availability.
How VMFS Datastore Growth Works
A datastore is a vSphere inventory object, while its storage is provided by one or more VMFS extents. Each extent occupies a partition on a storage device, usually a LUN from a SAN or other shared storage system.
There are two primary capacity-growth methods:
- Expand an existing extent: Increase the size of the backing LUN, then grow the existing VMFS partition and datastore into the newly available space.
- Add an extent: Present another compatible LUN, select a partition on that LUN, and join it to the existing datastore.
Both methods increase the aggregated capacity shown under one datastore name and inventory object. They differ in storage layout, failure dependencies, performance planning, and future migration complexity.
| Method | Storage change required | Contiguous space requirement | Uses an additional LUN | Primary benefit | Primary planning concern |
|---|---|---|---|---|---|
| Expand an existing extent | Enlarge the current backing LUN at the array, then expand VMFS | Yes; free space must immediately follow the existing extent | No | Retains a simpler, single-device layout | Array resize support and suitable partition geometry |
| Add an extent | Provision and present a new LUN, then add its partition to the datastore | No; the new device supplies the capacity | Yes | Works when the original LUN cannot be enlarged | More complex dependencies, pathing, performance, and failure planning |
Method 1: Expand an Existing VMFS Datastore Extent
In-place expansion is usually the preferred method when the storage array can safely enlarge the existing LUN. The array administrator first increases the LUN size. ESXi then discovers the larger device, and the VMFS datastore is expanded into the contiguous capacity at the end of the existing extent.
Required Layout
The available capacity must be on the same device and immediately after the current VMFS extent. Capacity elsewhere on the device, such as a gap before the partition or a noncontiguous region that the workflow cannot use, is not suitable for a simple in-place expansion.
For example, this layout can be expanded:
[ existing VMFS extent ][ unallocated capacity ]This layout cannot normally be expanded into the separated space by the standard workflow:
[ existing VMFS extent ][ other partition or gap ][ unallocated capacity ]High-Level vSphere Workflow
- Confirm the target datastore, its current capacity, free space, backing device, and extent layout.
- At the storage-array layer, enlarge the existing backing LUN using the array vendor's supported procedure.
- Rescan storage adapters on every relevant ESXi host so the new LUN geometry becomes visible.
- In the vSphere Client, select the target datastore and open its capacity-increase, expand, or increase-capacity action. The exact label can vary by vSphere version.
- Choose the option to expand the existing device or extent.
- Select the newly available contiguous space.
- Review the proposed capacity and partition change, then finish the wizard.
- Verify the resulting capacity and device paths on all hosts that use the datastore.
A LUN can generally be enlarged repeatedly as additional capacity becomes available, subject to the datastore and platform limits for the installed vSphere and VMFS versions.
Example: Expanding an Undersized Datastore
A datastore is backed by one LUN and is approaching full capacity. The storage administrator increases that LUN's size. After the ESXi hosts rescan their storage adapters, the vSphere administrator opens the datastore capacity workflow, selects the existing extent and newly visible contiguous space, reviews the change, and completes it. The virtual machines can remain running during the capacity increase.
Method 2: Add an Extent to a VMFS Datastore
An extent is a partition on an additional LUN that contributes capacity to an existing VMFS datastore. Adding an extent does not automatically happen when a new LUN is presented. The administrator must deliberately select the device through the datastore capacity-increase workflow.
High-Level vSphere Workflow
- Provision a new compatible LUN on the storage array.
- Present the LUN consistently to every ESXi host that requires access to the datastore. Confirm zoning, masking, identifiers, and storage policy requirements.
- Rescan storage adapters on the relevant ESXi hosts.
- Select the existing datastore in the vSphere Client and open its capacity-increase or expand action.
- Choose the option to add an extent.
- Select the eligible new device and the partition to use.
- Review the proposed extent and capacity configuration, then finish the wizard.
- Verify that all participating hosts see the same datastore and capacity.
The result remains one datastore name and one inventory object, but the datastore's capacity spans multiple LUNs. If any contributing LUN or its required storage paths becomes unavailable, the datastore can be affected. This makes extent layout, fault domains, path health, and performance consistency important design considerations.
Example: Adding a Separate LUN
An array cannot enlarge the original datastore LUN. A new LUN is provisioned and presented to every ESXi host using the datastore. After rescanning storage and confirming visibility, the administrator adds a partition from the new LUN as an extent. The datastore gains capacity without creating a second datastore, but its storage layout now depends on both LUNs.
Expansion Versus Extents
| Consideration | Expand existing extent | Add an extent |
|---|---|---|
| Best fit | The existing LUN can be enlarged and suitable contiguous space can be created | The original LUN cannot be enlarged or a separate LUN is required |
| Manageability | Usually simpler because the datastore remains on its existing device layout | More devices, partitions, paths, and dependencies must be documented |
| Performance | Usually preserves the current storage characteristics, although array behavior must still be checked | Performance may vary between LUNs, tiers, controllers, or array policies |
| Fault domain | Primarily depends on the existing LUN and its paths | Depends on every contributing LUN and its paths |
| Future migration | Often easier to understand and migrate as one backing device | May require more detailed planning because the datastore spans multiple devices |
Prefer expanding the existing LUN when contiguous capacity is available and the storage-array procedure is supported. Consider an extent when the original LUN cannot be expanded or a separate LUN is required. Before adding an extent, evaluate manageability, performance consistency, controller and failure domains, backup and monitoring behavior, and future migration or Storage vMotion plans.
Pre-Change Planning and Validation
- Identify the target: Confirm the datastore name, UUID if used in operational records, current capacity, free space, backing devices, and existing extent layout.
- Check array capacity: For an expansion, verify that the array has enough capacity and supports the required LUN resize. For an extent, provision a compatible new LUN.
- Validate host presentation: Ensure the current or new LUN is presented consistently to every ESXi host that needs datastore access.
- Rescan storage: Rescan the relevant ESXi storage adapters after array-side resizing or new LUN presentation.
- Check paths: Verify device visibility, multipathing configuration, active paths, and path health before changing the datastore.
- Check device ownership: Confirm the selected device is not already used by another datastore, another workload, or an unrelated partitioning arrangement.
- Document the change: Record the current datastore and extent configuration, storage identifiers, host membership, and intended final capacity. Follow change-control and backup procedures.
Historical Limits and Version Verification
Older VMware guidance commonly described a maximum of up to 32 extents or LUNs per datastore and a maximum datastore capacity of up to 64 TB. These figures are historical guidance, not a substitute for current product documentation.
| Item | Historical guidance | Version-specific verification needed |
|---|---|---|
| Extent count | Up to 32 extents or LUNs per datastore | Confirm the limit for the installed vSphere release, VMFS version, host configuration, and storage type |
| Datastore capacity | Up to 64 TB | Confirm the supported maximum for the installed vSphere and VMFS version and the selected device layout |
| LUN and device sizing | Subject to platform and storage limits | Check VMware compatibility guidance and storage-array limits before resizing or provisioning |
Do not design a datastore around historical maximums without checking the documentation applicable to the environment. Limits, supported workflows, and device requirements can differ by vSphere release, VMFS version, host configuration, and storage platform.
Post-Change Verification
- Confirm that the datastore reports the intended new capacity in the vSphere Client.
- Confirm that every participating ESXi host reports the same datastore capacity and remains connected.
- Verify the backing device or devices, extent layout, identifiers, and multipathing state.
- Browse the datastore and confirm that virtual machine directories, configuration files, virtual disks, and other expected files are accessible.
- Perform a controlled file or datastore operation, where appropriate, to verify normal read and write behavior.
- Check storage alarms, path failures, latency, and available-space monitoring after the change.
- Update capacity records, diagrams, monitoring thresholds, and operational documentation.
| Phase | Validation item | Expected result | Why it matters |
|---|---|---|---|
| Before | Datastore and extent inventory | Target datastore, capacity, free space, devices, and layout are documented | Prevents changing the wrong datastore or device |
| Before | Array capacity and LUN presentation | Resize or new LUN is supported and consistently presented | Ensures hosts can use the intended storage |
| Before | Rescan, paths, and multipathing | Devices are visible and paths are healthy | Reduces the risk of incomplete discovery or path loss |
| After | Datastore capacity on every host | All hosts report the intended identical capacity | Confirms cluster-wide consistency |
| After | Datastore access | Browsing and virtual machine file operations work normally | Confirms the datastore remains usable |
| After | Monitoring and paths | No unexpected alarms or path failures are present | Detects problems that may not appear in the capacity display |
Troubleshooting
Expanded LUN Capacity Is Not Available
Likely causes include an incomplete array-side resize, missing ESXi storage rescans, incomplete host presentation, or newly available space that is not contiguous with the existing extent.
- Confirm that the storage array reports the intended LUN size.
- Rescan storage adapters on each relevant ESXi host.
- Check the device capacity and partition layout reported by ESXi.
- Validate zoning, masking, device visibility, and multipath health.
- Confirm that the free capacity immediately follows the current VMFS extent.
New LUN Cannot Be Selected as an Extent
The LUN may not be visible to all required hosts, may already be claimed by another datastore or purpose, or may have an incompatible partition or device layout.
- Confirm consistent presentation to all hosts using the datastore.
- Check zoning, masking, identifiers, device claims, and existing datastore associations.
- Inspect device and partition information before proceeding.
- Do not select a device until its ownership and intended use are clear.
Hosts Report Different Capacity or Access
Inconsistent results commonly indicate incomplete rescans, inconsistent LUN presentation, a pathing problem, or a host that has not detected the updated device geometry.
- Compare device visibility and datastore capacity across all hosts.
- Rescan affected hosts and verify their storage adapters.
- Review active, standby, and failed multipath states.
- Pause workload changes until all relevant hosts report a consistent configuration.
The Datastore Must Be Made Smaller
Normal VMFS expansion does not provide an in-place shrink operation. If the datastore is now larger than required, migrate virtual machines and files to another datastore, or plan a replacement and migration workflow that safely creates the desired smaller layout.
Operational Checklist
- Choose the correct datastore and record its current state.
- Decide whether the existing LUN can be expanded safely.
- Prefer existing-extent expansion when contiguous capacity and supported array procedures are available.
- Use an extent only after evaluating its additional storage, performance, fault-domain, and migration dependencies.
- Present storage consistently and rescan all relevant ESXi hosts.
- Use the vSphere datastore capacity workflow; do not assume that presenting a LUN automatically expands VMFS.
- Review the proposed change before completing it.
- Verify capacity, datastore access, host consistency, paths, alarms, and monitoring afterward.
Summary
VMFS datastore capacity can be increased online by either expanding an existing extent or adding an extent from another LUN. Expanding the existing LUN is generally simpler and preferred when contiguous capacity is available. Adding an extent is useful when the original LUN cannot be enlarged, but it creates a datastore that depends on multiple storage devices. In both cases, careful host presentation, storage rescans, multipathing checks, version-specific limit verification, and post-change validation are essential.