VMware ESXi and vSphere Cluster Management
Expand a VMFS Datastore in VMware ESXi
Learn how to expand an existing VMFS datastore in VMware ESXi by using unallocated capacity on its backing LUN, including preparation, wizard steps, validation, and troubleshooting.
What VMFS datastore expansion does
VMFS is the VMware Virtual Machine File System used by ESXi datastores. A datastore is a storage container for virtual machine files, templates, ISO images, and related objects.
You can expand a VMFS datastore when its backing device—the disk or LUN on which the datastore resides—has additional unallocated capacity. A LUN is a logical storage device presented to an ESXi host.
This workflow increases the existing datastore. It does not delete or recreate the datastore, move virtual machines, or create a separate datastore. ESXi assigns eligible unused space on the same backing LUN to the existing VMFS filesystem.
Understand the types of available space
| Type of space | Location | Can this workflow consume it? |
|---|---|---|
| Free space inside the VMFS datastore | Already assigned to VMFS but not used by files | No. It is already part of datastore capacity. |
| Unallocated space on the backing LUN | On the same device, outside the existing VMFS allocation | Yes, if ESXi detects it as eligible space. |
| Capacity available only on a different LUN | Another storage device | No. Presenting another LUN does not automatically expand this datastore. |
Datastore expansion is generally a growth operation. It does not reduce datastore capacity. Shrinking a VMFS datastore is not the reverse of this workflow and requires separate planning, migration, and storage procedures.
Conditions required before expansion
- The ESXi host must detect the target LUN and its current size.
- The LUN must contain contiguous, eligible unallocated space that can be assigned to the datastore.
- You must have permissions to manage datastore capacity.
- You must be able to identify the correct datastore and backing device with confidence.
- The datastore must be a VMFS datastore that supports the available capacity operation.
If a storage administrator increased the LUN on a SAN, iSCSI, Fibre Channel, or local storage system, ESXi may initially continue to show the old device size. Rescan the relevant storage adapters or devices, then verify that ESXi reports the larger LUN before opening the datastore expansion workflow.
Pre-expansion planning and safety checks
| Check | What to verify | Why it matters |
|---|---|---|
| Target datastore | Name, VMFS type, current capacity, and current free datastore space | Prevents changes to the wrong storage container. |
| Backing device | LUN identifier, device identifier, paths, and reported size | Confirms that the unused capacity belongs to the intended datastore. |
| Expected result | Old capacity, available unallocated capacity, and expected final size | Provides a baseline for validating the operation. |
| Storage layout | Whether the unused region is unallocated and not reserved for another partition or datastore | Only eligible space can be added to VMFS. |
| Virtual machines | Active workloads, maintenance requirements, and operational impact | Supports change-control and monitoring decisions. |
| Protection and health | Recent backups, datastore health, path status, and storage alerts | Reduces risk before changing storage metadata. |
Record the datastore name, backing LUN, current capacity, current free capacity, expected final capacity, and the planned change time. Confirm that the apparent unused area is not intended for another partition or datastore.
Expansion normally does not require moving virtual machines off the datastore, but follow your organization’s change-control policy. Monitor active workloads and storage paths while the operation is performed.
Expand the datastore through the ESXi management interface
1. Rescan storage when the LUN was enlarged externally
When the storage array has been expanded, rescan the ESXi storage adapters or devices. The exact labels vary by ESXi and management-interface version, but the goal is to redetect adapters, paths, devices, and changed LUN capacity.
- Open the ESXi host management interface.
- Locate the storage adapters or storage devices view.
- Start a storage rescan, or rescan the relevant adapters and devices.
- Verify that the target LUN reports the new, larger size.
Do not proceed based only on the storage-array administrator’s confirmation. The capacity must also be visible from ESXi.
2. Open the datastore management view
- Select the relevant ESXi host in the inventory.
- Open the host’s related objects or related datastore list.
- Select the VMFS datastore that requires additional capacity.
- Start the action for increasing datastore capacity.
Depending on the interface version, the command may be presented as Increase datastore capacity or a similarly named action. Confirm that the selected object is the intended datastore before continuing.
3. Review the Increase Datastore Capacity wizard
- Confirm the datastore name and its current capacity.
- Review the eligible backing device shown by the wizard.
- Compare the device identifier and available space with your pre-change notes.
- Review the partition configuration choices.
- Select the configuration that uses the available free space on the same LUN.
- Check the displayed free-space value. This value is specific to the selected environment and may differ from the capacity originally expected.
- Review the summary carefully, then complete the wizard.
The partition configuration determines how available device capacity is assigned. Choose the option that consumes the eligible unallocated region for the existing VMFS datastore. Do not select a different device or partition layout merely because it displays capacity.
4. Allow ESXi to extend VMFS
After the final confirmation, ESXi updates the storage layout and extends the VMFS datastore. Wait for the task to complete. Do not interrupt the host, disconnect storage paths, or make simultaneous changes to the same LUN.
Example: expanding after a SAN LUN increase
A VMFS datastore currently occupies part of a 500 GB LUN. The storage administrator increases that LUN to 750 GB. The ESXi administrator then rescans storage and confirms that the backing device reports 750 GB.
In the capacity-increase wizard, the administrator selects the existing datastore, verifies the matching LUN, and chooses the partition configuration that uses the newly visible unallocated region. The existing datastore grows to use the assigned space; no second datastore is created and virtual machines remain associated with the original datastore.
Post-expansion validation
- Refresh the datastore inventory or storage view.
- Verify that the datastore’s total capacity increased by the expected amount.
- Confirm that the expected free datastore capacity is available.
- Inspect the backing device and confirm that its partition layout reflects the expanded VMFS allocation.
- Check that virtual machines, virtual disks, templates, ISO files, and other datastore contents remain accessible.
- Review storage paths, alerts, and task history.
- Record the old capacity, new capacity, backing LUN, operator, and completion time.
Remember that datastore capacity is the total usable size assigned to VMFS, while free datastore space is unused capacity within that VMFS allocation. The LUN’s remaining unallocated space is a separate value.
Validate shared datastore access
If several ESXi hosts use the same shared VMFS datastore, validate the result from every host or cluster member that should access it.
- Confirm that each host sees the datastore with the updated capacity.
- Confirm that the datastore remains mounted and accessible.
- Check that virtual machines can read their configuration and virtual disk files.
- Review path health and multipathing status.
- Investigate any host that still reports the old capacity or loses access.
Expanding the datastore on one host does not remove the need to verify shared visibility. All participating hosts must recognize the updated VMFS layout correctly.
Limitations and operational considerations
- Expansion depends on eligible free space on the same backing LUN.
- A different LUN with available capacity does not automatically enlarge the existing datastore.
- Increasing a LUN on a storage array and expanding VMFS in ESXi are separate operations.
- Storage rescans make changed device capacity visible; they do not themselves allocate that capacity to VMFS.
- The free region must be eligible in the device’s partition configuration. Capacity reserved for another layout cannot simply be consumed.
- Shrinking a VMFS datastore is not the reverse of expansion. Plan it as a separate operation, usually involving workload migration and careful storage management.
- Shared datastores require validation from all hosts that use them.
Common expansion problems
| Symptom | Likely cause | Recommended action |
|---|---|---|
| No free space appears in the partition configuration choices | The LUN was not expanded, ESXi has not detected the new size, the apparent free space is inside VMFS, or the region is not eligible. | Confirm capacity at the storage layer, rescan ESXi storage, inspect the device layout, and verify the selected backing device. |
| The LUN was enlarged on the array, but ESXi shows the old capacity | Adapters or devices were not rescanned, the array change is incomplete, pathing is affected, or the resized LUN is not correctly presented. | Rescan storage, verify device size and path health, and check LUN presentation at the array. |
| The wrong datastore appears selected | Similar datastore names or LUN identifiers were not checked before starting. | Cancel before completion if necessary. Match the datastore name, backing-device identifier, and current capacity against the change record. |
| The increase-capacity action is unavailable | Missing privileges, an incompatible datastore type, an inaccessible backing device, or a host-state problem. | Confirm permissions, verify that the target is an expandable VMFS datastore, and resolve host or storage connectivity problems. |
| The expected capacity is not visible after completion | The view has not refreshed, less unallocated capacity existed than expected, or the selected option did not consume all available space. | Refresh the inventory, compare before-and-after values, inspect the backing device, and review the selected partition configuration. |
| One shared-host member reports the old size | The host has stale storage information or a path or presentation issue. | Rescan and validate the host’s paths and datastore mount. Confirm the shared datastore from every participating host. |
Exam-relevant notes
- VMFS expansion uses unallocated capacity on the datastore’s backing device.
- Free space inside VMFS is already part of the datastore and is not added through this workflow.
- Storage-array expansion must occur before ESXi can use the new LUN capacity.
- A storage rescan makes changed device capacity visible but does not automatically expand the datastore.
- Always verify the datastore-to-LUN relationship before committing a capacity change.
- For shared VMFS storage, validate the expanded capacity and access from all relevant ESXi hosts.
For the complete procedure, use the VMFS datastore expansion guide as the change record for the operation.