VM Disk Full Can't Expand Root Volume Fix

Quick answer for experienced users

If your hypervisor shows you've added space but the OS still sees the old size, run partprobe or reboot, then resize the filesystem. If the disk is genuinely full inside the VM (root volume at 100%), you must free something (purge logs, remove old kernels, shrink a temp file) before you can expand—because the resize tools need a few MB of free space to operate.

Why this happens

You have a VM—maybe a Linux server or Windows Server—and monitoring shows the C: drive or root partition is 100% full. You go to your hypervisor (vSphere, Hyper-V, Proxmox) and increase the virtual disk size. But nothing changes inside the VM. Or worse: you reboot and the disk still shows full. What's actually happening here is that the OS's filesystem driver doesn't automatically see the new space. On Linux, you need to rescan the SCSI bus, extend the partition, and then grow the filesystem. On Windows, you use Diskpart or Disk Management to extend the volume. But the critical catch is: if the disk is logically full (100% inode or block usage), the extend operation can silently fail or even corrupt data. The system needs a tiny amount of free space to write the new metadata for the extended partition or filesystem.

Step-by-step fix (Linux example)

I'm using Ubuntu 22.04 LTS on VMware for this walkthrough. The steps are basically the same for RHEL, Debian, or any distro using LVM or direct partitions.

Free up space first — This is the step most guides skip. Run df -h and check if root is at 100%. If yes, delete old logs:
```
sudo journalctl --vacuum-time=1d  # instantly frees journald space
sudo apt clean                    # clears /var/cache/apt/archives
sudo rm -rf /tmp/*               # only if /tmp is on root
sudo rm -rf /var/log/*.gz        # rotate old syslog archives
```
The reason this matters: resize2fs needs at least a few MB free to safely extend the filesystem metadata. Without it, your system might lock up mid-resize.
Rescan the virtual disk in the hypervisor — After adding space in vSphere (increase disk size from 20GB to 30GB), rescan the SCSI bus without rebooting:
```
echo 1 > /sys/block/sda/device/rescan
# or use 'ls /sys/class/scsi_host/host*/scan' and echo '- - -' to each
```
On Hyper-V, this is trickier. You often need to run rescan inside Diskpart, or simply reboot. I prefer rebooting after expanding the disk in the hypervisor just to be safe—disconnect the network, reboot, then continue.
Extend the partition (non-LVM) — If you use a raw partition without LVM, use growpart:
```
sudo growpart /dev/sda 1   # extends partition 1 to fill new space
```
If growpart isn't installed, sudo apt install cloud-guest-utils on Ubuntu/Debian, or use fdisk manually to delete and recreate the partition with the same start sector—but that's risky.

Extend the LVM physical volume and logical volume — If you use LVM (most server VMs do):

sudo pvresize /dev/sda1   # tells LVM the partition got bigger
sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv   # for ext4
# For XFS, use: sudo xfs_growfs /mount/point

Verify — Run df -h again. You should see the new total size. If it's still the old size, you probably missed the partition rescan (step 2) or the filesystem type is different (XFS uses xfs_growfs, not resize2fs).

Alternative fixes when the main one fails

Sometimes you can't free any space because the VM won't even boot. Your only option then is a live CD rescue.

Use a GParted live ISO — Mount it in the hypervisor as a CD/DVD drive. Boot from it. Inside GParted, you can resize the Linux partition directly, even if it's 100% full. GParted works on the raw block device, not the mounted filesystem, so it doesn't need free space.
On Windows Server — If C: drive is completely full, boot from Windows Server ISO into recovery environment (RE). Open Diskpart, select volume, then extend. The RE has its own temporary workspace and doesn't need free space on C:.
Add a second virtual disk — If you absolutely cannot extend the root disk (maybe the hypervisor has a limit), add a fresh disk, mount it at /var or /home, and move large files there. This buys time.

Prevention tip

Set up a cron job that purges journald logs older than 7 days and runs apt clean. On Ubuntu/Debian, add this to /etc/cron.weekly/clean-vm:

#!/bin/bash
journalctl --vacuum-time=7d
apt clean -y

Also, configure logrotate for your apps. A full disk is almost always logs or temporary files. Thin-provisioned disks in VMware or Hyper-V need fstrim run periodically so the underlying storage actually releases freed blocks—otherwise the hypervisor thinks the disk is full even when the OS has free space. Run sudo fstrim -v / weekly.

A final opinion: never let a Linux root volume go above 85% if you can help it. The system needs headroom for temp files, package upgrades, and yes—filesystem resize operations. If you're reading this because you hit 100%, you're not alone. It happens to everyone at least once.