How to Expand a VM Disk and Grow the Filesystem on RHEL 9 / AlmaLinux (Online, No Reboot)

By /

Updated for 2026: originally written for RHEL 7 on vSphere. The dance hasn’t changed — grow the virtual disk, make the guest see it, grow the partition (if any), grow the filesystem — but the tooling is cleaner now (growpart, lvextend -r, XFS as the EL default). This version covers all three layouts you’re likely to meet on RHEL/AlmaLinux 9, online, without a reboot — plus the cases the original skipped: adding a partition to a disk that’s already in use, growing a partition on a disk in use with no LVM, when the root partition actually needs a reboot, and the fumbles every sysadmin makes on serious disk operations.

Step 0, whatever your layout: grow the disk and rescan

First expand the virtual disk in your hypervisor or cloud console (vSphere: edit VM settings; cloud: modify the volume). The guest won’t notice until you rescan the SCSI bus:

[root@server ~]# echo "- - -" > /sys/class/scsi_host/host0/scan
[root@server ~]# lsblk

lsblk should now show the disk at its new size. (On NVMe cloud volumes, the new size usually appears on its own.)

Now find your layout — it decides everything else:

[root@server ~]# lsblk -f

Layout A: filesystem directly on the disk (the original case)

No partition, no LVM — lsblk -f shows the filesystem (ext4 or xfs) on the disk itself, e.g. sdc. Grow the filesystem in place, online, even if it’s the root filesystem:

# ext4
[root@server ~]# resize2fs /dev/sdc

# xfs (XFS grows by mount point, not device)
[root@server ~]# xfs_growfs /

Layout B: a plain partition

Grow the partition into the new space first (growpart is in the cloud-utils-growpart package), then the filesystem:

[root@server ~]# growpart /dev/sda 3        # partition 3 on /dev/sda
[root@server ~]# resize2fs /dev/sda3         # ext4
[root@server ~]# xfs_growfs /                # xfs, if that's what's mounted

Layout C: LVM (the EL default install)

Three layers, one command each — and note that modern lvextend can grow the filesystem for you with -r:

[root@server ~]# growpart /dev/sda 3              # if the PV sits on a partition
[root@server ~]# pvresize /dev/sda3               # physical volume takes the new space
[root@server ~]# lvextend -r -l +100%FREE /dev/mapper/almalinux-root
[root@server ~]# df -h /                           # done — new size, no reboot

The -r flag handles resize2fs/xfs_growfs for whichever filesystem the logical volume carries, which is why this layout is the least error-prone of the three.

Adding a partition to a disk that’s already in use (no LVM)

The other direction: the disk has free space at the end and you want a new partition on it, not a bigger existing one. This is the common case on a data disk — a second disk was extended, or space was left unpartitioned at install time — and it is the operation people overthink. You do not need LVM for it, and you do not need a reboot, provided the disk is not the boot disk and the kernel can re-read the table.

[root@server ~]# lsblk                          # find the free space — the disk is bigger than its last partition
[root@server ~]# parted /dev/sdb mkpart primary xfs 100% 100%   # or: fdisk /dev/sdb, then n, p, defaults, w
[root@server ~]# partprobe /dev/sdb             # ask the kernel to re-read the table
[root@server ~]# lsblk                          # /dev/sdb2 (or sdb1) should now exist
[root@server ~]# mkfs.xfs /dev/sdb2             # or mkfs.ext4 — once, on the new partition
[root@server ~]# mkdir -p /data && mount /dev/sdb2 /data
[root@server ~]# blkid /dev/sdb2                # take the UUID for /etc/fstab — device names can move

Two details that matter. First, parted mkpart with 100% 100% takes all the remaining space; give it real start and end points if you want to leave room for a second partition later. Second, fdisk is interactive and its defaults are usually right — start sector defaults to the first free sector, which is what you want — but it only writes when you press w, and until then nothing has changed, so a wrong answer is free to abandon with q.

Growing a partition on a disk in use (no LVM)

This is Layout B from above, but with the failure modes spelled out, because this is where the reboot question actually lives. The steps are the same — growpart first, filesystem second — and the tool choice is the same too: growpart is the one-command online grower, parted resizepart is the general editor (parted /dev/sda resizepart 3 100%, then partprobe). What changes is what happens when the kernel refuses.

[root@server ~]# growpart /dev/sda 3
[root@server ~]# lsblk                          # did the partition actually grow?
[root@server ~]# partprobe /dev/sda             # if lsblk shows the old size, the table did not re-read
[root@server ~]# resize2fs /dev/sda3            # ext4 — or xfs_growfs / for XFS

If growpart or parted reports the device is busy, or lsblk still shows the old partition size after partprobe, the kernel would not re-read the partition table while the disk is in use. That is the one honest reason to reboot in this whole guide: the table is only re-read at boot when a partition on that disk is mounted and the kernel refuses the live re-read. It happens most often on the boot disk, on MBR-partitioned disks, and on older kernels; on a data disk with no mounted partitions it almost never happens. The fix is a reboot, then continue from pvresize or resize2fs — the reboot is for the table, not for the filesystem, and nothing you did before it is lost.

The root partition — probably a reboot, sometimes not

Root is the case the user is really asking about, so here it is plainly. Growing the root filesystem online needs no reboot — xfs_growfs / and resize2fs both work on a mounted root, and on LVM root the whole job is online (Layout C). Growing the root partition is where it splits. On a modern RHEL 9 / AlmaLinux 9 kernel, growpart on the root partition usually works online — the kernel can re-read the table when the partition being grown is the last one on the disk and the change is a pure extension. When it cannot — device busy, MBR disk, the partition is not the last one, or an older kernel — the answer is a reboot, and that is not a failure, it is the documented path: reboot, the table is read at boot with the new size, and you continue with pvresize / resize2fs / xfs_growfs. Shrinking root is never online: ext4 shrink needs the filesystem unmounted, and you cannot unmount / on a running system, so that job is rescue media or a live boot, full stop. And a non-LVM root on a plain partition is the same story with one fewer layer — partition first, filesystem second, reboot only if the table will not re-read.

Serious disk operations — the ones every sysadmin fumbles

Disk work is the operation every sysadmin fumbles at least once, usually at 2 a.m., usually on the disk that matters. The fumbles are always the same, and they are all layer mistakes — doing the right thing to the wrong layer, or in the wrong order:

  • Growing the filesystem before the partition. resize2fs on a partition that has not grown yet does nothing, and the admin concludes the disk did not extend. Check lsblk first: disk, partition, PV, LV, filesystem — find the layer that is still small.
  • Forgetting the rescan. The VMDK grew in vSphere, the guest never rescanned, and every command after that reports the old size. echo "- - -" > /sys/class/scsi_host/host0/scan (or the /sys/class/block/sdX/device/rescan form) is step zero, not an afterthought.
  • Snapshots blocking the extension. vSphere will not extend a disk with snapshots. Consolidate first, extend second — the error message arrives after you have already planned the maintenance window.
  • fdisk delete-and-recreate with the wrong start sector. The old way to grow a partition was to delete it and recreate it bigger, and it works — but only if the new partition starts at exactly the same sector as the old one. One sector off and the filesystem is gone. growpart exists so nobody has to do this any more; use it.
  • Shrinking in the wrong order. lvreduce before resize2fs destroys data past the new end. Filesystem first, LV second — or -r and let fsadm order it. And XFS never shrinks at all; the only way smaller is backup, recreate, restore.
  • Forgetting /etc/fstab. A new partition or a new swap LV that is mounted by hand and never added to fstab is gone at the next reboot, and the service that depended on it fails at boot. UUIDs, not device names — blkid gives you the UUID, and device names can move when disks are added.
  • Growing the wrong disk. sda vs sdb on a box with several disks, especially after a rescan renumbered something. lsblk before every destructive command, every time.

Verify

[root@server ~]# df -hT /

Filesystem size should match the new disk size (minus partition/LVM overhead). If df didn’t move but lsblk did, you grew a layer and skipped the next one down — re-check which layout you actually have.

Notes

  • XFS only grows. There is no supported shrink for XFS. ext4 can shrink, offline only, and it’s the kind of operation you rehearse on a snapshot first.
  • Snapshots: hypervisor snapshots block disk expansion in vSphere — consolidate them before you start, not after an error message.
  • Backup first anyway. Growing is one of the safest storage operations there is, and “safest” is not “safe”. A snapshot or backup you never need costs less than the alternative.

Running your own server? These guides assume you have a Linux box somewhere — see our guide to choosing a VPS in 2026 for the 7 specs that actually matter before you spin one up.

Scroll to Top