2.3Configuring and Managing LVM

Formatting a partition directly makes it hard to flexibly grow or shrink capacity later. LVM adds a layer of abstraction over physical disk constraints, enabling volumes to be extended, shrunk, and spread across multiple disks—even while the system is running—an indispensable tool in real operations.

2.3.1The three-layer LVM structure

• A physical volume (PV) is LVM's bottom-layer entity (a partition or a whole disk). Handled with pv commands: pvcreate (initialize as a PV), pvdisplay (detailed view), pvs (concise listing), pvremove (release a PV).
• A volume group (VG) is the middle layer that pools multiple PVs together. Handled with vg commands: vgcreate (build a VG from PVs), vgextend (grow a VG by adding a PV), vgreduce (remove a PV), vgdisplay/vgs (display).
• A logical volume (LV) is carved out of the VG pool as needed and is what actually gets a filesystem. Handled with lv commands: lvcreate (create from a VG), lvextend (grow), lvreduce (shrink), lvremove (delete), lvdisplay/lvs (display).

2.3.2The lvm command and lvm.conf

• lvm can invoke every PV/VG/LV subcommand (pvcreate, etc.) through a single interactive shell / unified front end (used as lvm pvcreate ..., or entering interactive mode by running lvm alone).
• lvm.conf controls LVM's overall behavior (which devices to scan, filters, logging, backup location, etc.). It typically runs fine at defaults; you edit it for special narrowing, such as restricting LVM to specific devices only.

LVM's real value is the operational flexibility to grow capacity without stopping the system when it runs low. Walk through a typical extension scenario. First add a disk, carve a partition, and turn it into a PV with pvcreate /dev/sdc1. Next, fold that PV into an existing VG (say vg_data) with vgextend vg_data /dev/sdc1—growing the VG. At this point the pool (VG) has more free space, but the actual LV in use (e.g., /dev/vg_data/lv_home) is still its original size, so you extend the LV itself with something like lvextend -L +20G /dev/vg_data/lv_home. The step most often missed is the final one: resizing the filesystem itself. Even after LVM grows the block device's capacity, the ext4 or XFS layer on top still thinks "my size is unchanged," so you must separately run a filesystem-level resize command—resize2fs for ext-family, or xfs_growfs for XFS (notably, XFS growfs can run while mounted)—before the added space becomes usable. Shrinking runs the opposite way: you must shrink the filesystem before shrinking the LV (lvreduce), and getting the order wrong risks data loss, so shrinking demands more caution than growing (ext4 can grow while mounted but must be unmounted (offline) to shrink, while XFS notably cannot shrink at all—an important practical asymmetry).

2.3.3Section summary

• PV (pv*) → VG (vg*) → LV (lv*), three layers. Create in order pvcreate → vgcreate → lvcreate; extend by adding a PV with vgextend, then growing the LV with lvextend
• After extending an LV, always also run a filesystem-level resize (resize2fs / xfs_growfs). When shrinking, the filesystem comes first. Overall behavior is controlled via lvm.conf