VMware ESXi and vSphere Cluster Management

Increase a Virtual Disk Size Online in VMware ESXi and vSphere

Learn how to expand an existing VMware virtual disk while a VM is running, then rescan and extend Windows or Linux partitions, LVM volumes, and file systems.

What Online Virtual Disk Expansion Does

Online, or hot, expansion increases the capacity of an existing virtual hard disk while its virtual machine remains powered on. A virtual disk is a virtual hard disk attached to a VM, commonly represented by a VMDK file.

The process has two separate stages:

1. vSphere stage: increase the provisioned capacity of the selected virtual disk.
2. Guest operating system stage: rescan the disk, enlarge the partition or volume, and grow the file system so applications can use the new space.

Completing only the vSphere stage leaves the added capacity as unallocated space. Unallocated space is disk capacity that has not yet been assigned to a partition or volume.

Requirements for Hot Disk Expansion

Thin provisioning initially consumes datastore space as data is written instead of reserving the full virtual capacity immediately. Thick provisioning reserves datastore capacity according to the disk's provisioning format. A thin disk can still contribute to datastore exhaustion after the guest begins using its added space.

Plan the Change Before Editing the VM

1. Identify the correct VM and exact hard disk. On a VM with multiple disks, compare the vSphere disk label, SCSI controller and unit position, current capacity, and guest disk identifier.
2. Record the current virtual disk size, guest disk layout, partition type, file system, mount point or Windows drive letter, and current utilization.
3. Confirm whether the disk is thin or thick provisioned and calculate the datastore space required for the intended new capacity.
4. Verify that the VM has no snapshots. Do not attempt online expansion while snapshots are present; handle them through the approved backup and change process.
5. Ensure that an appropriate backup or recovery point exists and that it can be restored or tested according to operational policy.
6. Choose a final size based on expected growth, retention, and monitoring requirements rather than only the current shortage.

Do not rely on a drive letter or a Linux device name alone. Device names can differ between the vSphere view and the guest, and controller positions matter when a VM has several disks.

Expand the Virtual Disk in vSphere

1. Open the VM from the vSphere inventory.
2. Open Edit Settings or the equivalent hardware configuration action.
3. In Virtual Hardware, locate the intended hard disk. Check its current size, controller, unit position, and backing information before changing it.
4. Change the provisioned disk capacity to a value larger than the current capacity. For example, change a secondary data disk from 100 GB to 150 GB.
5. Save the hardware change and wait for the reconfiguration task to complete successfully.
6. Reopen or refresh the hardware view and verify that the selected virtual disk displays the new capacity.

Detect the Larger Disk in the Guest

Many guest operating systems detect the larger virtual device automatically after the vSphere task completes. Others require a storage rescan or refresh. An operating-system rescan is different from the VMware virtual hardware change: the vSphere operation enlarges the virtual device, while the guest rescan makes the operating system re-read that device's size.

Before changing a partition or file system, confirm that the guest reports the larger device size. If it still reports the old size, rescan storage and verify that you are inspecting the disk mapped to the changed vSphere hard disk.

Extend Storage in Windows Guests

In Windows, use Disk Management or DiskPart to rescan disks, inspect the layout, and extend the intended volume into contiguous unallocated capacity.

Using Disk Management

1. Open Disk Management.
2. Rescan or refresh the disk view if the new capacity is not visible.
3. Identify the correct disk by its size and confirm the target drive letter or volume label.
4. Verify that the additional capacity appears as unallocated space immediately after the target volume.
5. Use Extend Volume on the intended volume and allocate the required space.
6. Confirm the volume's new size and available free space.

Using DiskPart

The following example rescans storage and extends a selected eligible volume. Replace the placeholder with the verified volume number.

diskpart
rescan
list disk
list volume
select volume <volume-number>
extend
exit

Confirm the selected volume before running extend. The target normally requires contiguous unallocated space immediately following it.

A recovery partition or another partition positioned after the main volume can prevent a simple extension, even when unallocated capacity exists elsewhere on the disk. Inspect the complete layout before choosing a layout-change, migration, or additional-disk strategy.

Extend Storage in Linux Guests

Linux expansion can involve several layers: the virtual disk, a partition, an optional LVM physical volume, an LVM logical volume, and the file system. Each required layer must be expanded in the correct order.

Inspect the Device and Layout

lsblk
sudo fdisk -l
df -h

Use the output to identify the expanded disk, partition number, mount point, file-system type, and whether LVM is involved. Device names such as /dev/sdX and partition names such as /dev/sdXN are examples only; replace them with verified values.

Conventional Partition and File-System Expansion

1. Rescan the relevant storage device if the kernel has not detected the new size.
2. Use a suitable partitioning utility, such as parted or fdisk, to enlarge the affected partition when the layout permits it.
3. Confirm that the partition now reaches the intended end of the disk.
4. Grow the file system with the command appropriate to its type.
5. Verify the mounted capacity and free space.

sudo parted /dev/sdX
sudo resize2fs /dev/sdXN
df -h

Use resize2fs for applicable ext-family file systems. For XFS, grow the mounted file system by specifying its mount point:

sudo xfs_growfs <mount-point>
df -h

Partition changes can be sensitive to the existing layout and partition table. Confirm backups and device identities before applying them.

LVM-Backed File Systems

LVM, or Linux Logical Volume Manager, adds a storage abstraction. A typical path is disk, partition, physical volume, volume group, logical volume, and file system. After the virtual disk grows, expand each applicable layer in order:

1. Rescan the disk and enlarge the partition if the physical volume occupies a partition.
2. Resize the LVM physical volume.
3. Extend the logical volume.
4. Grow the file system.
5. Verify the physical volume, logical volume, and mounted file system.

sudo pvresize /dev/sdXN
sudo lvextend -l +100%FREE -r /dev/<volume-group>/<logical-volume>
sudo pvs
sudo lvs
df -h

The -r option requests file-system resizing along with logical-volume expansion where supported. If the physical volume occupies the whole disk rather than a partition, use the verified disk device instead of a partition device.

Expansion Layers and Verification

Guest Operating System Follow-Up Tasks

Practical Examples

Windows Server Data Volume

A running VM has a secondary 100 GB virtual disk used for a data volume. Increase the disk to 150 GB in vSphere, wait for the reconfiguration task, and rescan storage in Windows. Disk Management should show approximately 50 GB of unallocated space after the existing data volume. Extend that volume and verify that its total capacity is approximately 150 GB.

Linux ext4 Partition

After enlarging a Linux data disk in vSphere, run lsblk to confirm the larger device. Enlarge the affected partition with an appropriate partitioning utility, grow the ext4 file system with resize2fs, and use df -h to confirm the mount point reports the added capacity.

Linux LVM Volume

For an LVM-backed file system, rescan the expanded device, enlarge its partition if one is used, run pvresize, extend the logical volume, and grow the file system. Verify each layer with pvs, lvs, lsblk, and df -h.

Validation and Post-Change Checks

1. Confirm that vSphere shows the intended virtual disk capacity.
2. Confirm that the guest block device reports the larger size.
3. Confirm that the partition, Windows volume, or LVM layers use the added space.
4. Confirm that the file system reports the intended final capacity.
5. Test that applications can read and write the expanded volume or mount point.
6. Review datastore free space after the change, especially for thin-provisioned disks.
7. Document the new capacity, disk mapping, change details, and recovery information.
8. Update monitoring thresholds, capacity alerts, and growth forecasts if necessary.

Troubleshooting

The Capacity Field Cannot Be Edited or the Change Fails

Check for snapshots first. Then confirm that the VM is powered on, the disk is a supported flat disk in persistent mode, and the administrator has permission to edit VM configuration. If the disk does not meet the online expansion requirements, use an approved alternative procedure.

The Guest Still Reports the Old Disk Size

The vSphere task may have completed while the guest has not rescanned storage. Refresh or rescan the guest devices, then compare disk identifiers, controller positions, and sizes to ensure the correct disk is being inspected.

Unallocated Space Exists but the Volume Cannot Be Extended

Inspect the entire partition map. The free space may not be contiguous with the target volume, or a recovery or other partition may sit between the volume and the new capacity. Use an approved layout-change, migration, or additional-disk strategy when a direct extension is not possible.

The Linux File System Did Not Grow

Enlarging only the virtual disk is insufficient. Use lsblk and LVM tools to determine whether the partition, physical volume, logical volume, or file system remains at its old size. Then apply the correct growth operation for the actual file-system type.

Datastore Free Space Is Critically Low

The new capacity may have exceeded available storage, thin-provisioned data may have begun consuming space, or concurrent VM activity may have used the remaining capacity. Review datastore utilization, add or reclaim storage according to policy, and configure suitable capacity alerts.

Operational Cautions

• Do not expand a disk online while snapshots are present. Resolve the snapshot condition through the approved backup and change process.
• Do not confuse expanding an existing virtual disk with adding a new virtual disk or presenting a raw LUN.
• Do not select a disk based only on its apparent position. Verify capacity, controller position, guest identifier, label, and mount point or drive letter.
• Remember that a larger virtual disk leaves unallocated capacity until guest-side partition, volume, and file-system work is complete.
• Expansion does not provide a substitute for backups, monitoring, or a tested recovery plan.

Related Administration Topics

For adjacent tasks, see adding virtual hardware to a VM, adding a raw LUN, datastore storage in vSAN, and assigning vSphere permissions.