LVM: The Logical Volume Manager Explained

LVM sits between your physical storage and your filesystems, adding a flexible abstraction layer that makes resizing volumes, spanning disks, and creating point-in-time snapshots possible without downtime. Once you've managed a system where a partition ran out of space at 2 a.m., you'll understand why LVM is the default choice on every serious Linux server deployment.

Core Concepts: PVs, VGs, and LVs

LVM organises storage in three layers:

• Physical Volume (PV) — a raw disk or partition handed to LVM. It can be /dev/sdb, /dev/nvme1n1, or a partition like /dev/sda3.
• Volume Group (VG) — one or more PVs pooled together into a single named storage reservoir. Think of it as a virtual disk whose capacity equals the sum of its PVs.
• Logical Volume (LV) — a slice carved out of a VG. This is what you format and mount. LVs are analogous to partitions, but resizing them is a matter of seconds rather than a partitioning adventure.

Under the hood, LVM divides every PV into fixed-size chunks called Physical Extents (PEs), typically 4 MiB. Every LV is allocated in terms of these extents, which is what makes live resizing and snapshots so clean.

Installing LVM Tools

Most server installs include LVM2 already. If not:

# Debian / Ubuntu
sudo apt install lvm2

# Fedora / RHEL / Rocky
sudo dnf install lvm2

# Arch
sudo pacman -S lvm2

Enable the LVM metadata daemon so that VG/LV changes are picked up cleanly at boot:

sudo systemctl enable --now lvm2-monitor.service

Step 1: Create Physical Volumes

Identify the disk or partition you want to add. Use lsblk or fdisk -l to confirm the device path, then initialise it as a PV. This destroys any existing data on that device.

sudo pvcreate /dev/sdb /dev/sdc

Inspect the result:

sudo pvs

Output will list each PV, its VG (empty for now), size, and free extents.

Step 2: Create a Volume Group

Pool those PVs into a VG. Choose a meaningful name — vg_data, vg_apps, etc. You can add more PVs later without interruption.

sudo vgcreate vg_data /dev/sdb /dev/sdc

sudo vgs

The VFree column shows space available for new LVs.

Step 3: Create Logical Volumes

Carve out LVs with lvcreate. Use -L for an absolute size or -l with a percentage for relative allocation.

# Fixed size: 50 GiB LV named lv_db
sudo lvcreate -L 50G -n lv_db vg_data

# Use 100% of remaining free space for lv_backup
sudo lvcreate -l 100%FREE -n lv_backup vg_data

Format and mount the LV like any block device — its path is /dev/vg_data/lv_db (or equivalently /dev/mapper/vg_data-lv_db):

sudo mkfs.ext4 /dev/vg_data/lv_db
sudo mkdir -p /mnt/db
sudo mount /dev/vg_data/lv_db /mnt/db

Add a persistent /etc/fstab entry using the device path or UUID (blkid to find it).

Step 4: Resize Logical Volumes

This is where LVM earns its keep. Resizing is live on most filesystems.

Grow an LV and its filesystem

Extending ext4 or XFS is non-destructive and can happen while the volume is mounted.

# Add 20 GiB to lv_db
sudo lvextend -L +20G /dev/vg_data/lv_db

# Resize the ext4 filesystem to fill the new space immediately
sudo resize2fs /dev/vg_data/lv_db

For XFS (the default on RHEL/Fedora family), use xfs_growfs instead — and the volume must be mounted:

sudo xfs_growfs /mnt/db

You can combine the LV extension and ext4 resize in one command with the -r flag:

sudo lvextend -L +20G -r /dev/vg_data/lv_db

Shrink an LV (ext4 only, unmounted)

XFS cannot be shrunk. For ext4, unmount first, check the filesystem, shrink the filesystem, then shrink the LV — in that order. Reversing the order corrupts data.

sudo umount /mnt/db
sudo e2fsck -f /dev/vg_data/lv_db
sudo resize2fs /dev/vg_data/lv_db 25G
sudo lvreduce -L 25G /dev/vg_data/lv_db

Extending a VG when you run out of PV space

Add a new disk to the VG without unmounting anything:

sudo pvcreate /dev/sdd
sudo vgextend vg_data /dev/sdd

Step 5: LVM Snapshots

A snapshot is a copy-on-write point-in-time image of an LV. It's ideal for consistent backups of live databases and for testing destructive operations.

Create a snapshot

The -s flag designates a snapshot. The size here is the change buffer — how much space is reserved to track divergence from the origin. Size it generously for active volumes.

sudo lvcreate -L 10G -s -n lv_db_snap /dev/vg_data/lv_db

Use and remove a snapshot

Mount the snapshot read-only, back it up, then discard it:

sudo mkdir -p /mnt/db_snap
sudo mount -o ro /dev/vg_data/lv_db_snap /mnt/db_snap

# Back up to a remote host, tar, rsync — whatever you need
rsync -aAX /mnt/db_snap/ backup-host:/backups/db/

sudo umount /mnt/db_snap
sudo lvremove /dev/vg_data/lv_db_snap

Revert to a snapshot (rollback)

If you need to roll an LV back to the snapshot state, unmount the origin and merge:

sudo umount /mnt/db
sudo lvconvert --merge /dev/vg_data/lv_db_snap

The merge completes on next activation. Remount after rebooting or deactivating and reactivating the LV.

Why LVM Beats Raw Partitions

• Online resizing — grow LVs and filesystems while services run.
• Span multiple disks — one logical volume can straddle several physical disks transparently.
• Snapshots — no application-level support required for consistent backups.
• Thin provisioning — allocate more logical space than physically exists (lvcreate --thin), growing physical storage as needed.
• Striping and mirroring — built-in RAID-like performance and redundancy without a dedicated RAID controller.
• Renaming and moving — pvmove migrates data off a failing disk live, vgrename renames VGs cleanly.

Verification

After any LVM operation, verify the full stack is intact:

sudo pvs   # physical volumes
sudo vgs   # volume groups
sudo lvs   # logical volumes

For detailed output including PE allocation and attributes:

sudo pvdisplay
sudo vgdisplay
sudo lvdisplay

Confirm mounts and filesystem usage:

df -hT /mnt/db

Troubleshooting

VG not found at boot

If a VG fails to activate at boot, run sudo vgchange -ay to activate all VGs. Check that lvm2-activation-generator ran properly via systemctl status lvm2-activation-early.service. On systems with an initramfs (virtually all of them), regenerate it after LVM changes to the root VG:

# Debian/Ubuntu
sudo update-initramfs -u

# Fedora/RHEL/Rocky
sudo dracut --force

# Arch
sudo mkinitcpio -P

Snapshot fills up and invalidates

If the snapshot's change buffer fills completely, LVM marks it invalid and it becomes useless. Monitor snapshot usage with sudo lvs -o +snap_percent and size snapshots generously for write-heavy volumes. lvextend can grow a snapshot's buffer while it is active.

lvreduce fails with filesystem resize errors

Always run e2fsck -f before resize2fs on a volume you intend to shrink. If the filesystem reports errors, fix them before proceeding. Never shrink the LV to smaller than the filesystem size — LVM will warn you but will not always stop you.