You grew the virtual disk in vSphere, Proxmox or Hyper-V, and the guest still reports the old size. Nothing inside Linux notices a disk that changed size behind its back, so the extra space has to be walked up the stack by hand: disk → partition → physical volume → volume group → logical volume → filesystem. Every layer has to be told separately, and skipping one is why "I extended the disk and nothing happened" is such a common complaint. This is the whole sequence for an LVM partition on RHEL 8/9, CentOS, AlmaLinux 9, Rocky Linux 9 and Ubuntu, online, with no reboot.
Step 1. Rescan the disk so Linux sees the new size
echo '1' > /sys/class/scsi_disk/0\:0\:0\:0/device/rescan
0:0:0:0 is the SCSI address (host:channel:target:LUN), not a fixed string — it is almost always 0:0:0:0 for the first disk of a virtual machine, but confirm it rather than assume:
lsscsi
ls /sys/class/scsi_disk/
If you prefer not to guess, rescan every attached disk:
for d in /sys/class/scsi_disk/*/device/rescan; do echo 1 > "$d"; done
Check that it worked before going any further — lsblk must show the new size of /dev/sda while the partitions still show the old one:
lsblk /dev/sda
dmesg | tail -5 # "sda: detected capacity change from ... to ..."
If the size has not changed, stop here. Nothing downstream can work, and the usual reasons are that the hypervisor change was not applied, or the disk has a snapshot attached.
Step 2. Extend the LVM partition with parted resizepart
parted /dev/sda
Use print to see the layout, then resize. Below, the fourth partition is grown into all the free space — -0 means "to the end of the disk":
print
resizepart 4 -0
quit
Two things parted will say, and what they mean:
- Not all of the space available to /dev/sda appears to be used… Fix/Ignore? — answer Fix. On a GPT disk the backup header still sits at the old end of the disk; this moves it. It is safe and it is required.
- Warning: Partition /dev/sda4 is being used. Are you sure you want to continue? — yes. Growing the last partition in place does not touch the data in it, and the kernel picks up the new size without unmounting anything.
The hard constraint: resizepart only works if the partition is the last one on the disk. If there is anything after it — a second data partition, a swap partition — you cannot grow it this way. Add a new virtual disk instead, run pvcreate on it and vgextend the volume group; LVM does not care that the space comes from a second device, and it avoids rewriting a partition table under a live filesystem.
Confirm the partition table was re-read:
partprobe /dev/sda
lsblk /dev/sda
Step 3. Grow the physical volume and the logical volume
The PV still knows only its old size, so pvresize first, then check what the volume group actually gained:
pvresize /dev/sda4
vgdisplay rhel | grep "Free"
lvextend -L+500.00G /dev/mapper/rhel-aux1
vgdisplay rhel uses the volume group name, which is rhel on a default Red Hat install, cl on CentOS 8, ubuntu-vg on Ubuntu — run vgs if you are not sure. If you simply want everything that is free, skip the arithmetic:
lvextend -l +100%FREE /dev/mapper/rhel-aux1
Step 4. Grow the filesystem
This is a separate operation on the LVM partition: lvextend gives the logical volume more blocks, and the filesystem inside it still stops where it did before.
xfs_growfs /dev/mapper/rhel-aux1
Or, on ext4:
resize2fs /dev/mapper/rhel-aux1
You can collapse steps 3 and 4 into one by adding -r (--resizefs), which calls the right tool for whatever filesystem is on the volume:
lvextend -r -l +100%FREE /dev/mapper/rhel-aux1
"xfs_growfs: /dev/mapper/cl-root is not a mounted XFS filesystem"
This error comes from an older xfs_growfs, not a newer one. Until xfsprogs 5.0.0-2 (December 2019) the tool took a mount point and nothing else; that release added "xfs_growfs: allow mounted device node as argument" and the synopsis changed from mount-point to [ mount-point | block-device ]. Eric Sandeen spells this out in Red Hat bug 1885875, which is this exact error filed against RHEL 8.0.
So the direction is the opposite of what it looks like: RHEL 8.2+, RHEL 9, CentOS 8, AlmaLinux 9 and Rocky Linux 9 all ship past that fix and accept the device happily. You only meet this message on an older box — RHEL or CentOS 7, or RHEL 8.0/8.1:
> Error: xfs_growfs: /dev/mapper/cl-root is not a mounted XFS filesystem
The fix works everywhere, old and new: pass the directory where the filesystem is mounted instead of the device. For the root filesystem that is simply /:
# xfs_growfs /
meta-data=/dev/mapper/cl-root isize=256 agcount=14, agsize=877824 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0 spinodes=0 rmapbt=0
= reflink=0
data = bsize=4096 blocks=12055552, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 12055552 to 16248832
The last line is the confirmation you want: data blocks changed from … to ….
Ubuntu: the cloud-image variant
Ubuntu server images from a cloud or a template usually have no free space at the end of the disk to hand to parted, because cloud-init's growpart module already grew the partition to the template's disk size on first boot. (On a plain-partition image it is the cloud-initramfs-growroot script that does it; that one bails out on a device-mapper root, so it is not what runs on an LVM layout.) Growing the disk again later is a manual pass, and growpart — from the cloud-guest-utils package — does step 2 in one command:
growpart /dev/sda 4
pvresize /dev/sda4
lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
The filesystem on Ubuntu is normally ext4, so resize2fs — or lvextend -r — is what finishes the job.
Verify
lsblk
pvs ; vgs ; lvs
df -hT /
lvs must show the new logical volume size and df the new filesystem size. If lvs grew but df did not, step 4 did not run or ran against the wrong device.
One warning before you size it
Plan the size of the LVM partition properly, because the way back is not symmetrical. Red Hat's documentation is explicit that it is not possible to decrease the size of an XFS file system — there is no xfs_shrink, and the only route back is backup, mkfs, restore. ext4 can be shrunk with resize2fs, but only offline, which on a root filesystem means a rescue boot. Adding 500 GB you do not need is a decision you live with.
If the volume you are growing sits on an iSCSI LUN rather than a local virtual disk, the scan step is different — see how to add an LVM volume on a new iSCSI disk for the initiator-side rescan and the _netdev trap in /etc/fstab.
