When working with VMware virtual machines, expanding a virtual disk is just the first step in the storage expansion process. The real challenge comes when you need to make the additional space available to your Linux system without rebooting - particularly when dealing with LVM Physical Volumes (PVs).
Before proceeding, verify that:
# Check current disk size
lsblk
# Verify VMware tools are running
ps aux | grep vmtoolsd
# Check kernel version
uname -r
1. Refresh Disk Capacity in Kernel
For SCSI disks with LSI Logic controller:
# Rescan SCSI bus
echo 1 > /sys/class/scsi_device/0\:0\:0\:0/device/rescan
# Alternative method for newer kernels
echo "- - -" > /sys/class/scsi_host/host0/scan
2. Partition Table Manipulation
Using parted
instead of fdisk
for online operations:
# Start parted interactive mode
parted /dev/sda
# In parted shell:
(parted) print free
(parted) resizepart 2 100%
(parted) quit
3. PV Extension
pvresize /dev/sda2
# Verify with:
pvs
4. LV and Filesystem Operations
# Extend the logical volume (20G example)
lvresize -L +20G /dev/vg00/root
# For ext4 filesystems
resize2fs /dev/vg00/root
# For xfs filesystems
xfs_growfs /
If the kernel doesn't recognize the new size:
# Try blockdev reread
blockdev --rereadpt /dev/sda
# Or force partition table reload
partprobe /dev/sda
For systems with growpart
(common in cloud images):
growpart /dev/sda 2
When expanding a virtual disk in VMware, the hypervisor correctly reports the new size through the SCSI layer, but many administrators encounter a frustrating roadblock: Linux's cached partition table doesn't automatically reflect the changes. The kernel maintains this cached version of the partition table from the initial boot, and traditional tools like fdisk
or sfdisk
will continue showing the old disk geometry.
For newer kernels (3.6+), the solution is straightforward:
# Rescan the entire SCSI bus
echo 1 > /sys/class/scsi_device/0\:0\:0\:0/device/rescan
# Alternatively, for specific device (adjust sdX accordingly)
echo 1 > /sys/block/sdX/device/rescan
For legacy systems (kernel 2.6.x), we need a more nuanced approach:
# First delete and recreate the device mapping
echo 1 > /sys/class/scsi_disk/0\:0\:0\:0/device/delete
# Then trigger a bus rescan
echo "- - -" > /sys/class/scsi_host/host0/scan
After executing these commands, verify the new size with:
cat /proc/partitions
# Or alternatively
blockdev --getsize64 /dev/sdX
Let me walk through a complete real-world scenario where we expand a 100GB disk to 200GB:
# 1. VMware disk expanded from 100GB to 200GB
# 2. Rescan the SCSI bus (new kernel method)
echo 1 > /sys/block/sda/device/rescan
# 3. Verify new size
blockdev --getsize64 /dev/sda
# Should now show 214748364800 (200GB)
# 4. Delete old partition and create new with fdisk
fdisk /dev/sda
# Command sequence: d (delete), n (new), p (primary), 1 (partition number),
# Accept defaults for first/last sectors, t (type), 8e (LVM), w (write)
# 5. Inform kernel about partition table change (critical!)
partprobe /dev/sda
# 6. Resize PV
pvresize /dev/sda1
# 7. Check free space in VG
vgdisplay
# 8. Extend LV
lvextend -l +100%FREE /dev/vg00/lvol0
# 9. Resize filesystem (ext4 example)
resize2fs /dev/vg00/lvol0
If you encounter "Device or resource busy" errors when trying to delete/recreate partitions:
- Ensure no processes have open handles to the disk (use
lsof | grep /dev/sdX
) - For root partitions, you might need to boot from rescue media
- Some DM-multipath configurations require additional steps
For more complex scenarios, consider these alternatives:
# Using parted for GPT disks
parted /dev/sda resizepart 1 100%
partprobe
Remember that while the partition table update is the most challenging step, the subsequent LVM operations (pvresize
, lvextend
, resize2fs
) are generally more straightforward.