LVM on Ubuntu: Create & Resize Volumes

Fixed partitions are a planning trap: size them too small and you run out of space; too large and you waste it. LVM (Logical Volume Manager) removes that guesswork. It adds a flexible layer between your physical disks and your filesystems, so you can grow a volume, add a disk to a pool, or move data between disks—often without downtime. This is the same elasticity that cloud block storage gives you, implemented locally on Ubuntu.

This guide builds an LVM stack from scratch on Ubuntu 24.04: turning raw disks into physical volumes, grouping them into a volume group, carving out a logical volume, putting a filesystem on it, and then growing that filesystem online while it stays mounted. We finish with verification and the pitfalls that trip people up.

The three LVM layers

LVM has three stacked concepts. A Physical Volume (PV) is a raw disk or partition handed to LVM. One or more PVs join a Volume Group (VG), a single pool of storage. From that pool you allocate Logical Volumes (LVs), which behave like partitions you can format and mount. The power is that LVs are not tied to a single disk and can be resized after creation.

Prerequisites

• Ubuntu 24.04 LTS with sudo access.
• At least one spare, unused disk (this guide uses /dev/sdb and later /dev/sdc). All data on these disks will be destroyed.
• The LVM tools, which are usually preinstalled. If not: sudo apt update && sudo apt install lvm2.

Step 1: Identify your disks

List block devices to confirm which disks are free:

lsblk

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   50G  0 disk
└─sda1   8:1    0   50G  0 part /
sdb      8:16   0   20G  0 disk
sdc      8:32   0   20G  0 disk

Here sda is the OS disk; sdb and sdc are empty 20 GB disks we will use. Double-check you are not about to wipe something important.

Step 2: Create a physical volume

Initialize the first disk as an LVM physical volume:

sudo pvcreate /dev/sdb

  Physical volume '/dev/sdb' successfully created.

Verify:

sudo pvs

Step 3: Create a volume group

Create a VG named data-vg containing the PV:

sudo vgcreate data-vg /dev/sdb

sudo vgs

Step 4: Create a logical volume

Carve a 10 GB logical volume named web-lv out of the group:

sudo lvcreate -L 10G -n web-lv data-vg

To instead use a percentage of free space—say all of it—use -l:

sudo lvcreate -l 100%FREE -n web-lv data-vg

The new device appears at /dev/data-vg/web-lv (and a matching path under /dev/mapper/). Confirm:

sudo lvs

Step 5: Create a filesystem and mount it

sudo mkfs.ext4 /dev/data-vg/web-lv

Create a mount point and mount it:

sudo mkdir -p /srv/web
sudo mount /dev/data-vg/web-lv /srv/web

To make the mount persistent across reboots, add it to /etc/fstab using the LV's UUID. Get the UUID:

sudo blkid /dev/data-vg/web-lv

Then add a line to /etc/fstab (replace the UUID with yours):

UUID=xxxx-xxxx  /srv/web  ext4  defaults  0  2

Test the fstab entry without rebooting:

sudo systemctl daemon-reload
sudo mount -a
df -h /srv/web

Step 6: Grow the volume online (the payoff)

This is why LVM earns its place. Say /srv/web is filling up. First, add capacity to the volume group by initializing the second disk and extending the VG:

sudo pvcreate /dev/sdc
sudo vgextend data-vg /dev/sdc

The VG now has more free space. Extend the logical volume and grow the filesystem in one command with -r (resizefs), all while it stays mounted:

sudo lvextend -r -L +15G /dev/data-vg/web-lv

The +15G adds 15 GB to the current size; -r automatically runs resize2fs for ext4 afterward. To grow into all remaining free space instead:

sudo lvextend -r -l +100%FREE /dev/data-vg/web-lv

If you ever extend the LV without -r, grow the filesystem manually:

sudo resize2fs /dev/data-vg/web-lv

Step 7: Verify the new size

df -h /srv/web
sudo lvs
sudo vgs

The df output should show the larger filesystem, available immediately with no unmount and no reboot:

Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/data--vg-web--lv   25G  104M   24G   1% /srv/web

Note how the device-mapper name doubles the dashes in data-vg to data--vg—that is normal LVM escaping, not a typo.

Common pitfalls and troubleshooting

• Wiping the wrong disk. pvcreate destroys data. Always confirm with lsblk that the target disk is empty and unmounted first.
• Forgetting to grow the filesystem. lvextend alone only grows the block device; the filesystem stays the same size until you run resize2fs (ext4) or xfs_growfs (XFS). Use -r to do both at once.
• XFS cannot shrink. ext4 can be shrunk (offline); XFS can only grow. Choose accordingly if you might need to reduce a volume.
• fstab typos cause boot failures. A bad /etc/fstab line can drop the system to emergency mode at boot. Always test with sudo mount -a before rebooting, and use UUIDs rather than device names.
• VG out of space. If lvextend fails with insufficient free extents, add a disk with pvcreate + vgextend first, as in Step 6.

Conclusion

LVM gives a single Ubuntu host the kind of elastic storage that used to require careful upfront partitioning: pool your disks, allocate what you need today, and grow online tomorrow. The pvcreate → vgcreate → lvcreate → lvextend -r workflow is worth committing to memory.

The same idea scales out across a cluster. Distributed storage like a Ceph cluster on Ubuntu pools disks across many nodes, and in OpenStack you consume that capacity as elastic Cinder block volumes you attach to instances on demand. That is exactly how clouditiv delivers resilient, growable storage in its managed on-premise cloud—the flexibility of LVM, at data-center scale, without you babysitting disks.