LVM Basics

An ordinary partition has a fixed size, bounded by its position on the disk. If the disk fills up, extending the partition usually means repartitioning the entire disk. LVM (Logical Volume Manager) solves exactly this problem by adding a flexible layer on top of disks and partitions: it pools multiple disks into a single capacity pool and carves out logical volumes of whatever size is needed from that pool.

This article is the next step after Partitions — once a physical partition is ready, it shows how to turn it into flexible LVM storage. Resizing a volume later and taking snapshots continues in LVM: Resizing and Snapshots.

What You Will Learn

By the end of this article you will be able to:

• explain the PV, VG, and LV concepts and the relationship between them;
• create a new LVM structure with pvcreate, vgcreate, lvcreate;
• check the current state with pvs, vgs, lvs, and lvdisplay;
• distinguish LVM device-mapper names (/dev/mapper/...) from an ordinary partition name;
• remove an LV/VG/PV in the correct order with lvremove, vgremove, pvremove;
• judge when to choose an ordinary partition versus LVM.

The Three-Layer Model: PV, VG, LV

LVM consists of three layers:

Physical Volume (PV)  →  Volume Group (VG)  →  Logical Volume (LV)
   /dev/sdb1                  vg_data              lv_app, lv_logs
   /dev/sdc1

• Physical Volume (PV) — a disk or partition on which LVM metadata is written. A raw disk (/dev/sdb) or an ordinary partition (/dev/sdb1) can both be a PV.
• Volume Group (VG) — a shared capacity pool combining one or more PVs. A VG's size equals the sum of every PV in it.
• Logical Volume (LV) — a logical partition carved out of a VG, on which a filesystem is created. Unlike an ordinary partition, its size can be changed at any time within the limits of the VG.

When to Use LVM

LVM is useful, but not always necessary. On a small, single-disk server whose volume size will never change, an ordinary partition may be sufficient.

Required Package

On the Debian/Ubuntu family:

sudo apt update
sudo apt install lvm2

Once lvm2 is installed, commands like pvcreate, vgcreate, lvcreate become available.

Building a New LVM Structure

Suppose /dev/sdb and /dev/sdc are two empty disks.

1. Create Physical Volumes

sudo pvcreate /dev/sdb /dev/sdc

Checking the result:

sudo pvs
sudo pvdisplay

pvs gives a short table, pvdisplay gives detailed information.

2. Create a Volume Group

sudo vgcreate vg_data /dev/sdb /dev/sdc

vg_data is the VG's name; the second and subsequent arguments are the PVs added to it. Checking:

sudo vgs
sudo vgdisplay vg_data

The VSize column in vgs output shows the combined size of both disks.

3. Create a Logical Volume

sudo lvcreate -n lv_app -L 20G vg_data

• -n lv_app — the LV's name;
• -L 20G — an exact size (in gigabytes, for example).

To give an entire VG's capacity to a single LV, rather than only a portion:

sudo lvcreate -n lv_app -l 100%FREE vg_data

-l (lowercase) refers to a percentage or extent count, while -L (uppercase) refers to an exact byte size.

A new LV is visible through device-mapper via two equivalent paths:

/dev/vg_data/lv_app
/dev/mapper/vg_data-lv_app

Both point to the same device; fstab and other configuration typically use the first, more readable form.

4. Create a Filesystem and Mount It

sudo mkfs.ext4 /dev/vg_data/lv_app
sudo mkdir -p /mnt/app
sudo mount /dev/vg_data/lv_app /mnt/app

For a permanent mount, writing to /etc/fstab via UUID is recommended — covered in depth in fstab.

sudo blkid /dev/vg_data/lv_app

Commands for Checking the Current State

lsblk

Sample output:

NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sdb                   8:16   0   10G  0 disk
└─vg_data-lv_app    253:0    0   20G  0 lvm  /mnt/app
sdc                   8:32   0   10G  0 disk
└─vg_data-lv_app    253:0    0   20G  0 lvm  /mnt/app

lsblk shows at a glance which disks are combined under which LV.

Removing an LV, VG, and PV

Removal is always done in the reverse order of creation: first the LV, then the VG, then the PV. If the order is broken — for example, trying to remove a VG that still has an LV in it — LVM stops with an error.

1. Remove the LV

If it's mounted, unmount it first:

sudo umount /mnt/app
sudo lvremove /dev/vg_data/lv_app

lvremove normally asks for confirmation (Do you really want to remove...); for scripted automation, add -y (or --yes):

sudo lvremove -y /dev/vg_data/lv_app

Checking:

sudo lvs vg_data

The removed LV should no longer appear in the list.

2. Remove the VG

Once no LV remains in the VG:

sudo vgremove vg_data

If the VG still contains an LV, vgremove fails with "Volume group ... contains ... logical volume(s)" — a safeguard against accidentally removing an entire group.

3. Remove the PV

After the VG is removed, LVM metadata can be stripped entirely from the disk or partition:

sudo pvremove /dev/sdb /dev/sdc

Checking:

sudo pvs

After pvremove, the disk can be reused for another purpose (for example, as an ordinary filesystem).

Two Operational Tasks LVM Makes Easy

Beyond creating volumes, two everyday LVM operations come up constantly in interviews because an ordinary partition simply can't do them.

Activating a VG After Moving Disks (vgchange)

When disks are physically moved to another server (or a VG isn't activated automatically), its LVs won't appear under /dev/mapper even though pvs/vgs can see them. LVM keeps its metadata on the PVs themselves, so it rebuilds the picture with a scan and an activation:

sudo vgscan                 # discover VGs on all PVs
sudo vgchange -ay vg_data   # activate every LV in the VG (-an deactivates)
lsblk

This is why an LV is described as active or inactive in lvs output — an inactive LV exists on disk but has no device node yet.

Migrating Data Off a Failing Disk Live (pvmove)

If SMART warns that one disk behind a VG is dying, its data can be moved onto another PV without downtime — the filesystem stays mounted and in use the whole time:

sudo pvcreate /dev/sdd            # a healthy replacement PV
sudo vgextend vg_data /dev/sdd    # add it to the VG
sudo pvmove /dev/sdb              # relocate every extent off the failing /dev/sdb
sudo vgreduce vg_data /dev/sdb    # remove the now-empty PV from the VG
sudo pvremove /dev/sdb            # strip LVM metadata; disk can be pulled

pvmove is resumable — if it's interrupted, running pvmove again with no argument continues the in-progress move. This ability to evacuate a disk with zero downtime is one of LVM's strongest real-world advantages over plain partitions.

Common Mistakes

Trying to Mount a PV Directly

A PV and a VG are not filesystems themselves — they're just LVM metadata. The only thing that can be mounted is a finished LV.

Confusing VG Size with Total Disk Size

VFree in vgs output is the space not yet allocated to any LV. When creating a new LV, this is the column to check, not the physical disk size.

Mixing Up -L and -l

-L 20G is an exact size, -l 50%FREE is a percentage of the free space. The two can't be used at the same time.

Exercises

1. In a disposable VM, add two extra virtual disks and combine them into a single VG.
2. Compare pvs, vgs, and lvs output — note what each column represents.
3. Allocate half a VG's capacity to one LV and the rest to another. Check both sizes with lvs.
4. Trace the disk → PV → VG → LV chain in the lsblk tree.

Verification criterion: given a VG's VFree value, you should be able to say the maximum size an lvcreate -L can request without failing.

Summary

LVM adds PV → VG → LV layers to disk management, freeing capacity from the boundary of a single partition. A new structure is built with the pvcreate, vgcreate, lvcreate trio, and the current state is tracked with pvs/vgs/lvs. The next article, LVM: Resizing and Snapshots, shows how to extend this LV while it's in use and how to take a snapshot of it.

References

• Red Hat: LVM Architecture Overview
• man7.org: lvm(8)
• man7.org: pvcreate(8)
• man7.org: vgcreate(8)
• man7.org: lvcreate(8)