LVM The Linux Sysadmin’s Guide to Flexible Storage

As a Linux sysadmin, managing storage can be a juggling act. You need to provision space for various applications, handle growing storage demands, and ensure data protection. This is where LVM (Logical Volume Manager) steps in as a game-changer. Let’s dive into how LVM empowers you with flexible and scalable storage management.

What is LVM?

LVM is a storage abstraction layer that sits between your physical disks and the file systems you use. It introduces the concept of:

• Physical Volumes (PVs): These are your actual storage devices (hard drives, SSDs) or partitions.

• Volume Groups (VGs): PVs are combined into VGs, creating a pool of storage capacity.

• Logical Volumes (LVs): VGs are divided into LVs, which are the “virtual disks” you work with. LVs can be formatted with a file system and mounted for use.

Why LVM? Key Advantages

• Flexibility: Easily resize LVs without downtime, even when they’re in use.

• Scalability: Add or remove storage to your VG as needed.

• Snapshots: Create point-in-time copies of LVs for backups and testing.

• Striped Volumes: Combine multiple PVs for improved performance.

• Mirroring: Duplicate data across PVs for redundancy and fault tolerance.

Setting Up LVM: A Step-by-Step Guide

Let’s walk through the process of creating a simple LVM setup:

• Identify Your Physical Storage: sudo fdisk -l This lists your available disks. Decide which ones to use for LVM.

• Create Physical Volumes (PVs): sudo pvcreate /dev/sdX  # Replace sdX with your device

• Create a Volume Group (VG): sudo vgcreate my_vg /dev/sdX /dev/sdY # Add all PVs

• Create Logical Volumes (LVs): sudo lvcreate -L 10G -n my_lv my_vg   # 10GB LV named my_lv

• Format and Mount: sudo mkfs.ext4 /dev/my_vg/my_lv sudo mount /dev/my_vg/my_lv /mnt/my_storage

Resizing LVs: The Power of Flexibility

One of LVM’s biggest strengths is resizing. Need to make an LV bigger?

• Extend the VG (if needed): sudo vgextend my_vg /dev/sdZ  # Add another disk if necessary

• Extend the LV: sudo lvextend -L +5G /dev/my_vg/my_lv # Add 5GB

• Resize the Filesystem: sudo resize2fs /dev/my_vg/my_lv # Adjust ext4 filesystem

• Shrinking LVs: Shrinking is a bit trickier. First, shrink the filesystem, then the LV.

Snapshots: Your Safety Net

LVM snapshots are like “freezes” of your LVs.

• Create a Snapshot: sudo lvcreate -L 5G -s -n my_lv_snap /dev/my_vg/my_lv

• Mount and Use: Treat the snapshot like any other LV.

Important: Snapshots use copy-on-write space to track changes to the origin LV. When the snapshot fills up, it becomes invalid (returns I/O errors) — you must remove it and create a new one.

Advanced LVM: Stripping and Mirroring

• Stripping: Spread an LV across multiple PVs for better performance.

• Mirroring: Duplicate an LV across PVs for redundancy.

Consult LVM documentation for details on setting these up, as they involve additional steps.

Best Practices

• Plan Ahead: Design your VG layout with future growth in mind.

• Regular Backups: Even with snapshots, have a solid backup strategy.

• Monitor Space: Keep an eye on your VG and LV usage.

• Test Changes: Practice on a non-production environment before applying to live systems.

Conclusion

LVM is a powerful tool that can greatly simplify your storage management. By mastering its concepts and techniques, you’ll gain the ability to create flexible, scalable, and resilient storage solutions for your Linux systems.

Related Reading

• the lost+found Directory in Linux
• LVM Advanced: Snapshots, Thin Provisioning, and Not Losing Your Data
• Three ways to upload ISOs to Proxmox
• Time Sync on VMs: Why NTP Keeps Drifting
• ddrescue vs TestDisk vs PhotoRec

Things That Will Bite You (and How to Not Let Them)

The docs won’t tell you these, but your 2 AM self eventually finds out the hard way.

Shrinking without unmounting first

Shrinking an ext4 LV while it’s mounted is a great way to corrupt a filesystem. The order matters and it’s the opposite of extending:

# CORRECT order for shrinking — do NOT skip steps
sudo umount /mnt/my_storage
sudo e2fsck -f /dev/my_vg/my_lv          # force check before touching it
sudo resize2fs /dev/my_vg/my_lv 8G       # shrink filesystem first
sudo lvreduce -L 8G /dev/my_vg/my_lv     # then shrink the LV
sudo mount /dev/my_vg/my_lv /mnt/my_storage

Extend = resize LV first, then filesystem. Shrink = filesystem first, then LV. Get it backwards and you’re explaining to your team why the database partition is now a brick.

The snapshot size trap

You already know snapshots go invalid when they fill up. What catches people off guard is how fast that happens on a busy volume. Write-heavy databases, log directories, anything doing constant I/O — your 5G snapshot is full before your backup script even finishes.

Rule of thumb: size your snapshot at 15-20% of the origin LV for light workloads, 50%+ for anything database-adjacent. If you’re regularly taking snapshots for backups, look into thin provisioning instead — it handles the COW pool much more gracefully.

You can check snapshot usage before it goes sideways:

sudo lvs -o lv_name,lv_size,data_percent,snap_percent

The snap_percent column is the one that keeps you employed. Set a cron alert if it crosses 70%.

VG name collisions after cloning VMs

If you clone a VM (Proxmox, anyone?) and both VMs end up with the same VG name, vgscan gets confused about which one is which. LVM uses UUIDs internally, but the name collision causes vgchange -ay to throw fits during boot.

Fix it before you boot the clone:

# On the cloned VM (while the disk is attached elsewhere or in rescue mode)
sudo vgrename old_vg_name new_unique_name
# Then update /etc/fstab if you reference by device mapper path

This is the kind of thing that only happens once, but it happens to everyone eventually.

Don’t fill a VG to 100%

Leave 5-10% free in your VG. Metadata operations, snapshot COW overhead, and thin pool management all need breathing room. A VG at 100% will let you down at the worst possible moment — usually when you’re trying to take a snapshot because something is already going wrong.

# Quick health check — run this regularly
sudo vgs --units g
sudo lvs --units g

If VFree is approaching zero, it’s time to either vgextend with a new disk or have a serious conversation with whatever process is eating all your space.