Grow a Linux disk after extending a VMDK

Extending a virtual disk in vSphere takes about fifteen seconds. The part that surprises people is what happens next: the guest reports exactly the same free space it had before, and it keeps reporting it until four more layers are told about the change.

Between the VMDK and the directory that ran out of space sit a SCSI device, a partition, an LVM physical volume, a logical volume and a filesystem. Each has its own idea of how big it is, and each is grown by a different command. Miss one and the extra space stays invisible.

This walks the whole chain on one machine, from the vSphere dialog to df showing the new number, and names what differs between the RHEL family and Debian or Ubuntu, because the final step is not the same command on both.

Applies to: vSphere 7 and 8, with Rocky Linux 9 and Ubuntu Server 22.04 as the guests. The same sequence applies to RHEL, AlmaLinux, Oracle Linux and Debian.

The chain, end to end

Six steps, one per layer. This table is the whole article in short form: if you already know the sequence and only need the commands, work down it.

The machine and its starting state

One VM is used throughout: SRV-LNX-01, Rocky Linux 9, a single 60 GB disk with the standard installer layout. Record the starting state before touching anything. When a later step appears to do nothing, this is what you compare against.

# Devices, partitions, sizes and mount points
lsblk

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   60G  0 disk
|-sda1        8:1    0    1G  0 part /boot
`-sda2        8:2    0   59G  0 part
  |-rl-root 253:0    0   55G  0 lvm  /
  `-rl-swap 253:1    0    4G  0 lvm  [SWAP]

# Filesystem type and free space. The T matters - it tells you xfs or ext4,
# which decides the command in step 6.
df -hT /

Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/mapper/rl-root xfs    55G   52G  3.0G  95% /

# Is there any unused space already inside the volume group?
sudo vgs
sudo lvs

VG #PV #LV #SN Attr   VSize   VFree
rl   1   2   0 wz--n- <59.00g      0

LV   VG Attr       LSize
root rl -wi-ao---- <55.00g
swap rl -wi-ao----   4.00g

VFree 0 is the line that matters. Nothing is spare inside the volume group, so the space has to come from outside, which is what the next five steps arrange.

Step 1. Extend the VMDK

In the vSphere client, right-click the VM, choose Edit Settings, expand Hard disk 1 and raise the size. 60 becomes 80. Apply, and the task finishes in seconds.

[Screenshot placeholder – vSphere Edit Settings dialog with Hard disk 1 expanded and the size field changed from 60 to 80 GB]

Nothing has changed inside the guest yet. That is expected, and it is where most people stop and wonder why.

df -hT /

Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/mapper/rl-root xfs    55G   52G  3.0G  95% /

Step 2. Make the guest see the new size

The kernel read the disk geometry at boot and has no reason to look again. Tell it to.

# Rescan just this device. Replace sda with the disk you extended.
echo 1 | sudo tee /sys/class/block/sda/device/rescan

If the disk was added rather than extended, or you are not sure which device it is, rescan every SCSI host instead. Both are safe and both are online operations.

# The three dashes mean "any channel, any target, any LUN"
for h in /sys/class/scsi_host/host*/scan; do echo "- - -" | sudo tee "$h" > /dev/null; done

Confirm the kernel now sees 80 GB. The partition is still the old size, which is correct at this stage.

lsblk /dev/sda

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   80G  0 disk
|-sda1        8:1    0    1G  0 part /boot
`-sda2        8:2    0   59G  0 part

Step 3. Grow the partition

growpart rewrites the partition table so the last partition uses the new free space. It handles GPT and MBR, and it works on a mounted partition.

# Note the space: the disk and the partition NUMBER are two arguments,
# not /dev/sda2. This is the single most common error with this command.
sudo growpart /dev/sda 2

CHANGED: partition=2 start=2099200 old: size=123731968 end=125831167 new: size=165675007 end=167774207

Check it before going further. If the command is missing, install it: the package is cloud-utils-growpart on the RHEL family and cloud-guest-utils on Debian and Ubuntu.

lsblk /dev/sda

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   80G  0 disk
|-sda1        8:1    0    1G  0 part /boot
`-sda2        8:2    0   79G  0 part

Use the dry run first if you want to see the plan without writing anything.

sudo growpart -N /dev/sda 2

Steps 4 and 5. Grow the LVM layers

LVM stores the physical volume size in its own metadata, so it also has to be told. pvresize reads the partition again and updates it.

sudo pvresize /dev/sda2

Physical volume "/dev/sda2" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

The volume group now has free extents. This is the moment the space becomes usable.

sudo vgs

VG #PV #LV #SN Attr   VSize   VFree
rl   1   2   0 wz--n- <79.00g  20.00g

Now give that free space to the logical volume that needs it. +100%FREE takes everything available; use -L +10G instead when you want to keep some in reserve.

sudo lvextend -l +100%FREE /dev/mapper/rl-root

Size of logical volume rl/root changed from <55.00 GiB to <75.00 GiB.
Logical volume rl/root successfully resized.

Step 6. Grow the filesystem, and this is where distributions differ

The logical volume is bigger, the filesystem inside it is not. This last command is the one that differs, and running the wrong one produces an error that reads like a broken system when it is only the wrong tool.

On the Rocky machine in this walk-through, the filesystem is xfs and the argument is where it is mounted.

# xfs_growfs takes the MOUNT POINT, not the device.
# Passing /dev/mapper/rl-root here fails with "not a mounted XFS filesystem".
sudo xfs_growfs /

data blocks changed from 14417920 to 19660800

On Ubuntu with the default ext4 layout, the same step is the other way round.

# resize2fs takes the DEVICE, not the mount point.
sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

Filesystem at /dev/mapper/ubuntu--vg-ubuntu--lv is mounted on /; on-line resizing required
The filesystem on /dev/mapper/ubuntu--vg-ubuntu--lv is now 19660800 (4k) blocks long.

Step 6b. Verify

Three commands confirm the whole chain took, from the device up to the filesystem.

lsblk /dev/sda
sudo vgs
df -hT /

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   80G  0 disk
`-sda2        8:2    0   79G  0 part
  `-rl-root 253:0    0   75G  0 lvm  /

VG #PV #LV #SN Attr   VSize   VFree
rl   1   2   0 wz--n- <79.00g      0

Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/mapper/rl-root xfs    75G   52G   23G  70% /

[Screenshot placeholder – terminal showing lsblk and df -hT side by side, before on the left and after on the right]

When there is no LVM

Cloud images and minimal installs often put the filesystem straight on a partition, with no volume group in between. The chain is then four steps instead of six: extend the VMDK, rescan, grow the partition, grow the filesystem.

# Confirm there is no lvm layer - lsblk shows part directly under disk
lsblk /dev/sda

# Rescan and grow the partition exactly as before
echo 1 | sudo tee /sys/class/block/sda/device/rescan
sudo growpart /dev/sda 1

# Then the filesystem, directly on the partition
sudo xfs_growfs /            # RHEL family
sudo resize2fs /dev/sda1     # Debian and Ubuntu

What goes wrong

Tips and limitations

• Growing is online and safe. Shrinking is neither: xfs cannot be shrunk at all, and shrinking ext4 requires unmounting. Plan sizes upward only.
• Take a backup or a snapshot before the first time you do this on a production VM, and remove the snapshot afterwards so the next extend is not blocked by it.
• Extending the VMDK consumes datastore space immediately on a thick disk and gradually on a thin one. Check the datastore, not just the guest.
• lvextend -r does steps 5 and 6 in one command and picks the right filesystem tool for you. Use it once you have done the sequence manually and understand what it is doing.
• On a machine with several disks, confirm which /dev/sdX matches the VMDK you extended before rescanning. Growing the wrong partition table is not something LVM will warn you about.
• An MBR disk cannot go past 2 TB. If the disk needs to grow beyond that, it has to be converted to GPT or the space added as a second disk.
• /boot is usually a plain partition outside LVM, and it is rarely the one that fills up. If it does, the fix is removing old kernels, not resizing.

Official documentation

• Change the Virtual Disk Configuration – VMware vSphere 8.0 | Broadcom TechDocs
• Configuring and managing logical volumes | Red Hat Enterprise Linux 9
• growpart – Ubuntu manpage

Related tools

• PowerCLI Command Builder – build the PowerCLI call when you would rather extend the disk from a script than from the UI.

Related guides

• Get-VMGuestDisk: guest disk free space with PowerCLI – find which VMs are about to need this before they page you.
• Connect to a Linux server from Windows – how to get to the shell where all of this runs.
• Linux commands cheat sheet – the surrounding commands for disks, mounts and space.
• Linux cheat sheet for Windows admins – the same layers, mapped from diskpart and Windows storage terms.
• The most useful ESXi and vCenter folders, tools and logs – where to look when the storage side is the problem.
• Windows disk and storage cheat sheet – the equivalent chain on a Windows guest.