When the disk of a virtual server is enlarged, the operating system does not use the extra space automatically — it arrives as unallocated space at the end of the disk. This guide covers making it usable on a server with LVM, without downtime beyond a single reboot.
To have the disk itself enlarged, order an upgrade first — see How do I upgrade my server or change plan?
These operations change the partition table of the disk your system is running from. A mistake here can leave the server unbootable.
Take a snapshot before you start — see Backups and snapshots for CloudVM virtual servers — and have console access ready: Managing your CloudVM virtual server in the client area.
1. See what you have
df -h lsblk
Note which volume needs enlarging and the name of its volume group. lsblk shows the disk size and the partitions on it, so the unallocated space at the end is visible as the difference between the two.
2. Create a partition in the new space
Adding a new partition is safer than resizing the existing one, because nothing already in use is touched.
fdisk /dev/sda
In fdisk:
n— new partition;p— primary;- accept the default partition number and the default first and last sectors, so the partition fills the free space;
t— change the type, then8efor Linux LVM;p— print the table and check it looks right;w— write the changes.
fdisk will warn that the kernel is still using the old table. On a system disk that is expected.
For disks larger than 2 TB, or with a GPT label, use parted or gdisk instead — fdisk on older systems cannot address them.
3. Reboot
reboot
On many systems partprobe is enough to re-read the table without restarting, but on the disk holding the running system it often is not. A reboot is the reliable route.
4. Add the partition to LVM
Create a physical volume on it:
pvcreate /dev/sda3
Find the volume group name:
vgs
Extend the group with the new partition:
vgextend VGNAME /dev/sda3
5. Extend the logical volume
Find the volume to enlarge:
lvs
Then give it all the free space in the group:
lvextend -l +100%FREE /dev/VGNAME/root
6. Grow the file system
The volume is now larger, but the file system on it is not. Which command you need depends on the file system — check with:
df -T
For XFS, the default on RHEL-based systems:
xfs_growfs /dev/mapper/VGNAME-root
For ext4, the default on Debian and Ubuntu:
resize2fs /dev/mapper/VGNAME-root
Both work on a mounted, running file system. Note that XFS can only be grown, never shrunk.
7. Check the result
df -h
The mount point should now show the new size.
If the server does not have LVM
Some images install without it, in which case there is no volume group to extend and the partition itself has to be resized — a riskier operation on a running system. Check with lsblk: if you see no lvm entries, open a ticket and we will advise on the approach for your setup.
Worth knowing
- Do this before the disk fills up. A full disk causes failures that look nothing like a disk problem — database errors, failed writes, sites partly working — and leaves less room to manoeuvre.
- Watch the free space afterwards. If it filled once, it will fill again; a monitoring check on disk usage is worth more than any single expansion.
If anything goes wrong, restore the snapshot rather than trying to unpick a partial change, and open a ticket from your client area describing the step you reached.
