Resizing a VPS Without Downtime: Growing Partitions, Filesystems and Verifying Hardware

Resizing a VPS is sold as a two-click operation: bump the plan, reboot, done. In practice the interesting failures happen after the reboot, when the kernel still reports the old CPU count, when the root filesystem refuses to grow because the partition table sits at the end of the disk, or when the new memory is present but a runaway process has already been OOM-killed during the transition. This runbook walks through what actually changes during a vertical upgrade and how to verify every layer before you trust it.

What the Provider Changes, and What It Does Not

A vertical resize on a KVM-based instance modifies the virtual hardware the hypervisor exposes: vCPU count, RAM allocation, and the size of the backing virtual disk. What it typically does not touch is anything inside the guest. The partition table, LVM physical volumes, filesystem superblocks, and the running kernel’s view of the hardware all remain exactly as they were. That gap is where most “the resize did not work” reports come from. If you are still deciding whether to stay on shared resources or move to a dedicated slice, the trade-offs are covered in this comparison of VPS hosting options before you commit to a plan change.

Before you touch anything, record the current state so you have a baseline to compare against:

nproc; free -m; lsblk; df -hT; uname -r; ip -brief addr

Growing the Disk: Partition, Then Filesystem

Increasing the virtual disk size only enlarges the block device. The partition inside it is still the old size, so df shows no change. The classic case is a single-partition GPT layout: the backup GPT header is pinned to the last sector, so growpart cannot extend the partition without first moving the header. growpart from cloud-guest-utils handles this automatically, but verify the result before resizing the filesystem:

growpart /dev/vda 1
lsblk /dev/vda
resize2fs /dev/vda1   # ext4; use xfs_growfs / for XFS

For LVM setups the order changes: pvresize first, then lvextend -r which grows both the logical volume and the filesystem in one step. Always confirm with df -hT afterward. A filesystem that reports the new size while lsblk still shows the old partition size means you resized the wrong layer and the next reboot may fail to mount.

Verifying CPU and Memory After the Reboot

CPU and RAM changes require a reboot because the guest OS caches the ACPI and SMBIOS tables it read at boot. Check nproc against the plan you purchased. A mismatch usually means the hypervisor did not apply the change (request a stop/start, not just a reboot) or the kernel was booted with a maxcpus= limit. Confirm memory with free -m and check dmesg | grep -i memory for the total the kernel detected.

Resizing Safely: A Pre-Flight Checklist

Even an in-place resize carries a small risk of failed mount on the next boot, so take a snapshot first if the provider offers one. Never resize while a database is mid-checkpoint or while a backup job is writing. After the operation, run your application’s health check and watch iostat -x 1 for a few minutes — a newly grown filesystem sometimes triggers a burst of metadata writes. The full sequence — snapshot, resize, grow layers, reboot, verify, smoke test — takes under fifteen minutes and eliminates the entire class of “it looked fine until it didn’t” incidents.

Every layer has to be grown in order; if you are weighing whether to upgrade an existing instance or start fresh, the VPS plans overview is worth reading before you commit to a new plan size.

Vertical resizing is reliable once you understand that the provider changes hardware and you change everything the guest sees. Treat the two as separate operations, verify each one, and the upgrade becomes a routine maintenance window rather than a gamble.