RH134 Chapter 11 — Managing Storage with Logical Volume Manager

Chapter Objective: Create and manage physical volumes, volume groups, and logical volumes with LVM, resize a logical volume's filesystem, and create an LVM snapshot.

Key commands: pvcreate, vgcreate, lvcreate, lvextend, lvreduce

Why LVM?

Chapter 10 covered partitioning a disk directly — simple, but rigid: a partition's size is fixed at creation, and it's tied to one specific disk. LVM (Logical Volume Manager) adds a flexible layer between raw storage and filesystems, letting you resize volumes, span multiple disks, and take snapshots without the constraints of traditional partitioning.

🔵 Why It Matters "This volume needs more space" is one of the most common storage requests an administrator gets. With LVM, that's often a quick, safe resize operation; with plain partitions, it can mean backing up data, repartitioning, and restoring.

LVM Building Blocks

Layer	Abbreviation	Role
Physical Volume	PV	A disk or partition initialized for LVM use
Volume Group	VG	A pool of storage combining one or more PVs
Logical Volume	LV	A resizable "virtual partition" carved out of a VG's pool

✅ Tip — Think of the VG as a Shared Pool A volume group pools space from all its physical volumes together. A logical volume draws from that combined pool, without caring which physical disk the space actually comes from — that's what makes spanning multiple disks and resizing so flexible.

Creating a Logical Volume, Start to Finish

# 1. Initialize a partition (or whole disk) as a physical volume
sudo pvcreate /dev/sdb1

# 2. Create a volume group from one or more physical volumes
sudo vgcreate data_vg /dev/sdb1

# 3. Create a logical volume from the volume group's pool
sudo lvcreate -n data_lv -L 10G data_vg

# 4. Create a filesystem on the new logical volume
sudo mkfs.xfs /dev/data_vg/data_lv

# 5. Mount it, ideally added to /etc/fstab for persistence (see Chapter 10)
sudo mkdir -p /data
sudo mount /dev/data_vg/data_lv /data

🔵 Note — Five Layers, One Path Each Time Physical volume → volume group → logical volume → filesystem → mount point. Every LVM task in this chapter works with one or more of these five layers — keeping them straight makes the commands much easier to remember.

Growing a Logical Volume

# Add more space to the volume group first, if needed
sudo pvcreate /dev/sdc1
sudo vgextend data_vg /dev/sdc1

# Grow the logical volume by a specific amount
sudo lvextend -L +5G /dev/data_vg/data_lv

# Or grow it to use ALL remaining free space in the VG
sudo lvextend -l +100%FREE /dev/data_vg/data_lv

# Grow the FILESYSTEM to match the larger logical volume (XFS)
sudo xfs_growfs /data

# Equivalent for ext4
sudo resize2fs /dev/data_vg/data_lv

⚠️ Warning — Growing the LV Doesn't Automatically Grow the Filesystem lvextend only resizes the logical volume itself. Without a follow-up xfs_growfs or resize2fs, the extra space exists at the LVM level but the filesystem on top still reports its old, smaller size.

✅ Tip — One-Step Combo lvextend -r -L +5G /dev/data_vg/data_lv resizes the logical volume AND its filesystem in a single command, when the filesystem type supports online resize (XFS and ext4 both do).

Shrinking a Logical Volume

Shrinking is riskier and more involved than growing — the filesystem must be shrunk first, and only then the logical volume, or data can be lost.

# ext4 example — XFS cannot be shrunk at all (recall Chapter 10)
sudo umount /data
sudo e2fsck -f /dev/data_vg/data_lv
sudo resize2fs /dev/data_vg/data_lv 8G
sudo lvreduce -L 8G /dev/data_vg/data_lv
sudo mount /data

⚠️ Warning — Shrink the Filesystem BEFORE the Volume, Never After Reducing the logical volume before the filesystem has been shrunk to fit can truncate the filesystem and destroy data. Always shrink top-down: unmount, shrink the filesystem, then shrink the volume — and back up first regardless.

Snapshots

An LVM snapshot captures a point-in-time view of a logical volume, useful for taking a consistent backup or testing a risky change with an easy rollback point.

# Create a snapshot of an existing logical volume
sudo lvcreate -s -n data_lv_snap -L 2G /dev/data_vg/data_lv

# Mount the snapshot to browse or back it up separately
sudo mkdir -p /mnt/snap
sudo mount /dev/data_vg/data_lv_snap /mnt/snap

# Remove the snapshot once it's no longer needed
sudo umount /mnt/snap
sudo lvremove /dev/data_vg/data_lv_snap

🔵 Note — A Snapshot Isn't a Full Backup A traditional LVM snapshot only stores the blocks that have changed since it was taken, and typically lives on the same underlying storage as the original. It's a convenient rollback point or a consistent source to back up FROM — not a substitute for a backup stored somewhere else entirely.

Viewing LVM Status

# Summary views
pvs
vgs
lvs

# Detailed views
pvdisplay
vgdisplay
lvdisplay

✅ Tip — s vs. display The short commands (pvs, vgs, lvs) give a quick one-line-per-item summary, good for a fast overview. The display variants give full detail on each item — reach for those when you need specifics like extent size or UUID.

Key Terms for Chapter 11

Physical Volume (PV): A disk or partition initialized for use by LVM
Volume Group (VG): A pool of storage space combining one or more physical volumes
Logical Volume (LV): A resizable volume carved out of a volume group's pooled space
lvextend: Grows a logical volume's size within its volume group
lvreduce: Shrinks a logical volume's size, only safe after the filesystem is shrunk first
snapshot: A point-in-time, changes-only view of a logical volume

Review Questions

What advantage does LVM offer over plain disk partitioning when a volume needs more space later?
Put physical volume, volume group, and logical volume in the correct order from "raw disk" to "resizable storage unit."
After running lvextend to grow a logical volume, why might df -h still show the old, smaller size?
Write the two commands needed to grow /dev/data_vg/data_lv by 5G and immediately grow its XFS filesystem to match.
Why must a filesystem be shrunk BEFORE the logical volume it lives on, never after?
Why can't an XFS-formatted logical volume be shrunk, regardless of the LVM commands used?
Is an LVM snapshot on its own a sufficient backup strategy? Why or why not?