Disk resize without a reboot

Four layers, and only one can be resized live in both directions

A disk on a virtual machine is not one thing. It is a stack, and a resize has to walk it from the bottom up:

1. The backing volume on the host — the actual blocks.
2. The virtual block device the guest sees as /dev/vda.
3. The partition table, if the guest is partitioned.
4. The filesystem — ext4, XFS — and possibly LVM in between.

Every layer must grow before the one above it can. Get the order wrong and you either achieve nothing or corrupt something.

Why it used to need a reboot

The guest kernel reads the block device's size when it attaches. Historically, growing the volume underneath changed nothing the guest could see — /dev/vda was still the old size until the device was re-enumerated, and the reliable way to do that was to reboot.

Modern virtio drivers handle a resize notification: the host signals that the device has changed, the kernel re-reads the capacity, and lsblk shows the new size without anything restarting.

The sequence

# 1. host: grow the backing volume
lvextend -L +50G /dev/vg0/instance-1234

# 2. host: tell the guest the device changed
virsh blockresize instance-1234 vda 130G

# 3. guest: confirm the kernel noticed
lsblk /dev/vda

# 4. guest: grow the partition (online, since util-linux 2.30)
growpart /dev/vda 1

# 5. guest: grow the filesystem
resize2fs /dev/vda1          # ext4
xfs_growfs /                 # XFS, by mountpoint not device

Steps 4 and 5 run on a mounted, live filesystem. That still makes people nervous, and it should not: ext4 and XFS have both supported online growth for well over a decade, and the operation is journalled. If it is interrupted, it is replayed or rolled back — not left half-applied.

Step 3 is the one that catches people

If lsblk still shows the old size, everything after it silently does nothing useful. growpart will report no change, resize2fs will say the filesystem is already the requested size, and you will conclude the resize failed when in fact it never reached the guest.

On an older kernel or a device attached over SCSI rather than virtio, force the re-read:

echo 1 > /sys/class/block/sda/device/rescan

Then check lsblk again before going further. Verifying the layer below before touching the layer above is the whole discipline here.

Shrinking is a different problem

Growing is safe because the new space is empty. Shrinking means moving data that already exists, and nothing can do that safely on a mounted filesystem.

XFS cannot shrink at all, by design. ext4 can, but only unmounted, and it requires a full filesystem check first. Which is why our resizes are one-directional: disk grows, never shrinks. If you genuinely need a smaller disk, the answer is a new instance and a copy — and we will do that for you rather than attempt an offline shrink on live data.

What about the snapshot?

Resize invalidates nothing, but it does change what a restore means. A snapshot taken at 80 GB, restored onto a 130 GB volume, gives you an 80 GB filesystem on a 130 GB device — correct, and then you run steps 4 and 5 again.

We take a snapshot before every resize regardless. It has never been needed for a growth operation. It costs about four seconds and it is the difference between a routine operation and one that requires courage.

In practice

Growing the disk on a KVM VPS takes about four seconds and no downtime. RAM and vCPU are different — those still need a reboot, because the guest sizes its memory map at boot — so a plan upgrade reboots once while a disk-only expansion does not.

Ask for one on +91 75994 50220 or from the panel. If you are doing it yourself on your own hardware, the order above is the whole trick: bottom layer first, verify each before the next.