Logical Volume Manager

Why this matters

A traditional partition is fixed. Its size was decided when the disk was partitioned, it must be contiguous, and it cannot span two disks. Run out of room in /var and your options are to delete things or rebuild the machine.

LVM removes all three constraints. It inserts a layer between the physical disks and the filesystems, so you can grow a volume, move it to a different disk while it is in use, or span it across several — with the system running.

That last part is why it is on the exam and why nearly every production Linux server uses it. "The database partition is full" stops being an outage and becomes a five-minute change.

The lesson

The three layers

LVM stacks three things. Learn the order and the commands follow, because every tool is named after the layer it works on.

  Filesystem (ext4, xfs)
      ↑
  LV   Logical Volume       — what you format and mount
      ↑
  VG   Volume Group         — a pool of storage
      ↑
  PV   Physical Volume      — a disk or partition given to LVM
      ↑
  /dev/sdb, /dev/sdc1 ...

Physical volumes are the raw contributions — whole disks or partitions, initialised for LVM use.

Volume groups pool one or more PVs into a single body of storage. The pool is what you allocate from, and it is what lets a logical volume span disks.

Logical volumes are carved out of a VG. They behave like partitions — you format and mount them — but they can be resized and moved.

Every command starts with the layer: pv*, vg*, lv*. Once you notice that, the twenty-odd commands become three families running the same handful of verbs — create, display, extend, remove, scan.

Building the stack

# 1. Physical volumes — hand disks to LVM
pvcreate /dev/sdb /dev/sdc
pvs                       # brief listing
pvdisplay                 # verbose, per PV
pvscan                    # scan all devices for PVs

# 2. Volume group — pool them
vgcreate data /dev/sdb /dev/sdc
vgs
vgdisplay data
vgscan

# 3. Logical volumes — carve it up
lvcreate -L 100G -n web data      # 100 GB, named "web"
lvcreate -l 50%FREE -n db data    # half the remaining space
lvcreate -l 100%FREE -n logs data # everything left
lvs
lvdisplay /dev/data/web

# 4. Format and mount as usual
mkfs.xfs /dev/data/web
mkdir /srv/web
mount /dev/data/web /srv/web

-L takes a size, -l takes an extent count or a percentage. Lower-case -l with 100%FREE is the idiom for "use the rest", and mixing the two flags up is the most common beginner error.

The device path appears in two equivalent forms: /dev/data/web and /dev/mapper/data-web. They are the same volume; lsblk shows the mapper name.

Growing a volume — the operation you will actually do

This is the payoff, and it is two steps that people conflate into one.

# 1. Grow the logical volume
lvextend -L +50G /dev/data/web        # add 50 GB
lvextend -l +100%FREE /dev/data/web   # take everything left in the VG

# 2. Grow the FILESYSTEM to fill it
resize2fs /dev/data/web               # ext4
xfs_growfs /srv/web                   # xfs — takes the MOUNT POINT, not the device

Growing the volume does not grow the filesystem. The LV gets bigger and df reports exactly the same free space, because the filesystem still believes it is the old size. This confuses people every single time.

The shortcut that does both:

lvextend -r -L +50G /dev/data/web     # -r resizes the filesystem too
lvresize -r -L 200G /dev/data/web     # set an absolute size

lvresize can grow or shrink; lvextend only grows. Prefer lvextend for growth precisely because it cannot shrink by accident.

Two facts worth committing:

• ext4 can be shrunk; xfs cannot. xfs has no shrink operation at all, at any size, ever. To make an xfs volume smaller you back up, recreate and restore. Choose accordingly.
• Shrinking is done in the opposite order. Filesystem first, then the volume — shrink the LV first and you have just truncated a filesystem that still thinks it owns those blocks, which destroys it. Unmount and e2fsck -f first.

Adding capacity to a full group

pvcreate /dev/sdd            # prepare the new disk
vgextend data /dev/sdd       # add it to the pool
vgs                          # confirm VFree has grown
lvextend -r -l +100%FREE /dev/data/web

Four commands, no downtime, no reboot. That sequence is the whole argument for LVM.

Moving data off a disk while it is in use

pvmove /dev/sdb              # migrate every extent off sdb, onto other PVs
pvmove /dev/sdb /dev/sdd     # onto a specific PV
vgreduce data /dev/sdb       # remove it from the group
pvremove /dev/sdb            # take back the LVM label

pvmove runs live. The filesystem stays mounted and applications keep writing while the data relocates. This is how you replace a failing disk, or migrate to faster storage, without an outage — and it is the single most impressive thing LVM does.

It is slow and it is interruptible; pvmove resumes if restarted.

Changing attributes and state

lvchange -an /dev/data/web       # deactivate — the device node disappears
lvchange -ay /dev/data/web       # activate
lvchange -p r /dev/data/web      # make it read-only
vgchange -an data                # deactivate the whole group
vgchange -ay data                # activate — needed after importing

Activation is what makes a volume's device node exist. A VG that shows in vgs but whose volumes have no /dev entry is deactivated — vgchange -ay is the fix, and this is exactly what happens after moving disks between machines.

Moving a volume group between machines

umount /srv/web
vgchange -an data          # deactivate
vgexport data              # mark it as exportable, detach from this host
# physically move the disks
vgimport data              # claim it on the new host
vgchange -ay data          # activate
mount /dev/data/web /srv/web

vgexport and vgimport exist so a VG is not accidentally claimed by two systems at once. Exporting marks it as belonging to nobody; importing takes ownership. Skip the export and the new host will usually still see it, but you have lost the safety interlock that stops shared storage being mounted twice — which corrupts filesystems.

Removing things

Removal runs down the stack in reverse:

umount /srv/web
lvremove /dev/data/web       # destroys the LV and its data
vgremove data                # the VG, once it has no LVs
pvremove /dev/sdb            # the PV label

lvremove prompts, and the prompt is the only thing between you and gone. There is no undo and no recycle bin — LVM removes the mapping, and the data goes with it.

Resizing a physical volume

pvresize /dev/sdb1           # after enlarging the underlying partition or LUN

Grow a virtual disk in the hypervisor, or a LUN on the SAN, and Linux does not automatically notice the partition can be bigger. pvresize makes LVM re-read the size so the new space becomes free extents in the VG. In a virtual machine the full chain is: grow the disk in the hypervisor, rescan the SCSI bus, grow the partition (growpart), then pvresize, then lvextend -r.

On the exam

• The stack is PV → VG → LV, and every command is named for its layer.
• lvextend grows the volume; the filesystem must be grown separately with resize2fs or xfs_growfs, or use -r to do both.
• xfs_growfs takes the mount point; resize2fs takes the device.
• xfs cannot be shrunk. ext4 can, offline, filesystem first.
• vgextend adds a disk to an existing group — the answer to "the volume group is full".
• pvmove relocates data with the filesystem mounted.
• vgchange -ay activates volumes; a VG whose devices are missing from /dev is simply inactive.
• vgexport/vgimport transfer a group between hosts safely.
• pvresize picks up a disk that grew underneath LVM.