Logical Volume Manager (LVM) Architecture: PV, VG and LV Provisioning | Linux Tutorial

In traditional Linux storage administration, filesystems were formatted directly onto raw block partitions (e.g., /dev/sdb1). While simple, this static partitioning model presents severe operational limitations: expanding a filesystem requires unmounting the volume, modifying the partition table, rebooting the system, and risking data corruption if sector boundaries are miscalculated. Furthermore, a single filesystem cannot span across multiple physical disks.

The Logical Volume Manager (LVM) abstracts physical storage into a flexible, virtualized pooling architecture. With LVM, systems administrators can concatenate multiple physical drives into dynamic pools, allocate virtual block devices on demand, extend volumes online without service downtime, and take instant point-in-time snapshots.

The LVM Three-Tier Abstraction Hierarchy

LVM organizes storage across three distinct architectural layers:

LVM Layer	Abbreviation	Architectural Role	Underlying Unit of Allocation
Physical Volume	PV	The physical foundation: a raw block storage device, NVMe drive, SSD, SAN LUN, or partition tagged with LVM metadata headers.	Raw sectors initialized with an LVM UUID and label.
Volume Group	VG	The centralized storage pool: aggregates one or more PVs into a unified capacity pool.	Sliced into uniform allocation chunks called Physical Extents (PE), typically 4 MiB by default.
Logical Volume	LV	The virtual partition: carved out of the VG, presenting as a standard block device (e.g., `/dev/vg_data/lv_app`) ready to format with ext4 or XFS.	Composed of Logical Extents (LE), each mapping directly 1-to-1 to a Physical Extent (PE) in the underlying Volume Group.

When an administrator writes data to a Logical Volume, LVM's device mapper kernel driver translates requests from Logical Extents (LE) to the corresponding Physical Extents (PE) distributed across one or more physical drives seamlessly.

Step-by-Step LVM Provisioning Workflow

Deploying a production-ready LVM storage volume follows a disciplined sequential pipeline:

1. Initialize Physical Volumes (PV)

Convert raw block devices (such as new SSDs /dev/sdb and /dev/sdc) into LVM physical volumes:

# Tag block devices as LVM Physical Volumes
sudo pvcreate /dev/sdb /dev/sdc

# Verify PV initialization, size, and assigned UUIDs
sudo pvs
sudo pvdisplay /dev/sdb

2. Create the Volume Group (VG)

Pool the initialized Physical Volumes into a named Volume Group:

# Create Volume Group 'vg_enterprise' using both physical volumes
sudo vgcreate vg_enterprise /dev/sdb /dev/sdc

# Verify total pool capacity, free extents, and PE size (default 4 MiB)
sudo vgs
sudo vgdisplay vg_enterprise

3. Allocate the Logical Volume (LV)

Carve a Logical Volume from the pool by specifying an absolute size (e.g., -L 50G) or a percentage of remaining free pool extents (e.g., -l 100%FREE):

# Allocate a 50 GB Logical Volume named 'lv_database' from 'vg_enterprise'
sudo lvcreate -n lv_database -L 50G vg_enterprise

# Verify LV creation and device-mapper path (/dev/vg_enterprise/lv_database)
sudo lvs

4. Format and Mount the Filesystem

Format the virtual block device with an enterprise filesystem (e.g., ext4) and mount it to the directory tree:

# Format the LV with ext4
sudo mkfs.ext4 /dev/vg_enterprise/lv_database

# Create mount point and mount the volume
sudo mkdir -p /srv/database
sudo mount /dev/vg_enterprise/lv_database /srv/database

# Retrieve the filesystem UUID for permanent fstab mounting
sudo blkid /dev/vg_enterprise/lv_database

Dynamic Volume Expansion (Online Storage Growth)

When an application volume nears full capacity, LVM enables seamless online capacity expansion without unmounting the filesystem or restarting services:

# 1. (Optional) Add a new physical drive (/dev/sdd) to the Volume Group if pool capacity is depleted
sudo pvcreate /dev/sdd
sudo vgextend vg_enterprise /dev/sdd

# 2. Extend the Logical Volume by adding 20 GB of extents
sudo lvextend -L +20G /dev/vg_enterprise/lv_database

# 3. Expand the filesystem to occupy the newly available volume space:
# For ext4 filesystems (online expansion):
sudo resize2fs /dev/vg_enterprise/lv_database

# For XFS filesystems (must specify mount point, not device path):
sudo xfs_growfs /srv/database

DANGER: Critical Warnings on Volume Reduction & Filesystem Constraints:

Volume Reduction Risks: Shrinking a Logical Volume (lvreduce) is a high-risk destructive operation. If the block device is reduced before the filesystem is safely shrunk, file headers are truncated, resulting in irreversible data loss. Always perform a complete backup prior to volume reduction.
ext4 Requires Offline Shrinking: While ext4 supports online expansion, it strictly requires taking the volume offline (umount) to shrink. The administrator must execute e2fsck -f, shrink the filesystem first with resize2fs, and only then shrink the LV.
XFS CANNOT BE SHRUNK: XFS filesystems do NOT support shrinking under any circumstance. By architectural design, the XFS metadata structure cannot be reduced. If an XFS volume must be made smaller, administrators must back up all data, delete the Logical Volume, recreate a smaller LV, format it with XFS, and restore the data.

Inspection and Health Telemetry

Systems administrators monitor LVM health and extent allocation using standardized reporting commands:

# Terse tabular overview across all three layers
sudo pvs
sudo vgs
sudo lvs

# Query free extents in a specific Volume Group
sudo vgdisplay vg_enterprise | grep -E "(Total PE|Alloc PE|Free PE)"

# Inspect block device mapper relationships and mount hierarchies
lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,UUID

Ensure that Volume Groups maintain a safety margin of unallocated Free PEs to facilitate online LVM snapshot creation for consistent database backups.