Ubuntu LVM Configuration Guide: Create, Extend, and Manage Disks Online Without Data Loss

Why Production Servers Should Use LVM Instead of Traditional Partitions

Your monitoring system fires an alert: the /data partition hosting a 150GB MySQL database has just hit 95% disk usage. If you are using traditional static GPT or MBR partitions, you face a painful dilemma. You have to request scheduled downtime, unmount the volume, and resize it using GParted. Services grind to a halt, and the risk of data corruption looms high.

LVM (Logical Volume Manager) handles this scenario effortlessly. It acts as an abstraction layer between physical storage devices and the filesystem. Instead of hardcoding directories to dedicated partitions, LVM aggregates multiple physical disks into a shared storage pool. From this pool, you can allocate volume capacity on demand based on real-world needs.

The system expands dynamically without requiring a reboot. Services continue running uninterrupted, guaranteeing zero downtime.

Before diving into configuration, you need to understand its three core architectural layers:

• Physical Volume (PV): Physical storage devices or raw partitions (such as /dev/sdb, /dev/nvme1n1). LVM writes metadata to the beginning of the disk for management.
• Volume Group (VG): A storage pool combining one or more PVs. You can add new disks to a VG at any time without disrupting the pool.
• Logical Volume (LV): A virtual partition carved out of a VG. You format a filesystem (ext4, XFS) onto this LV and mount it into the operating system just like a standard disk drive.

Environment Preparation on Ubuntu Server

Standard releases of Ubuntu Server 20.04/22.04/24.04 come with LVM tools pre-installed. However, if you are running minimal cloud images from AWS, Linode, or Hetzner, verify and install the lvm2 package:

sudo apt update && sudo apt install -y lvm2

Inspect the list of available block devices:

lsblk

Assume an empty 50GB disk at /dev/sdb has just been attached to the server. We will use this disk to configure a complete production-ready LVM setup.

Hands-On: Step-by-Step LVM Setup and Configuration

1. Initialize the Physical Volume (PV)

Convert the block device /dev/sdb into a PV managed by LVM:

sudo pvcreate /dev/sdb

The terminal outputs a confirmation message: Physical volume "/dev/sdb" successfully created.

2. Aggregate Disks into a Volume Group (VG)

Create a Volume Group named vg_data using the newly initialized /dev/sdb:

sudo vgcreate vg_data /dev/sdb

The vg_data pool now has a total capacity of 50GB. Later, if you add another 100GB disk like /dev/sdc, simply run sudo vgextend vg_data /dev/sdc. The pool expands to 150GB instantly.

3. Carve Out a Logical Volume (LV) and Format the Filesystem

Avoid allocating all available space right away. Carve out an initial 20GB from vg_data for your application partition (lv_app), leaving 30GB as reserve:

sudo lvcreate -L 20G -n lv_app vg_data

Create an ext4 filesystem on the newly provisioned volume:

sudo mkfs.ext4 /dev/vg_data/lv_app

Create a mount point and mount the volume into the directory tree:

sudo mkdir -p /mnt/data
sudo mount /dev/vg_data/lv_app /mnt/data

Configure automatic mounting across server reboots. Retrieve the LV’s UUID using blkid /dev/vg_data/lv_app, then append the entry to /etc/fstab:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/data ext4 defaults 0 2

4. Extend the Logical Volume Online When Storage Runs Low

Suppose after 3 months in production, the application grows and /mnt/data is running out of space. You need to expand it by 15GB using the unallocated space in vg_data.

Use the lvextend command with the -r (resizefs) flag:

sudo lvextend -L +15G /dev/vg_data/lv_app -r

The -r flag plays a crucial role. It instructs LVM to extend the logical volume and automatically resizes the underlying filesystem (supporting both ext4 and XFS) while mounted. You do not need to run resize2fs or xfs_growfs separately.

If you prefer to allocate 100% of the remaining free space in the VG to this volume, use the following syntax:

sudo lvextend -l +100%FREE /dev/vg_data/lv_app -r

Database and web server I/O operations continue seamlessly throughout the process. The system encounters no disconnects and zero service interruption.

Effective LVM Operations and Monitoring

SysAdmins should memorize three essential command pairs for quick and in-depth inspection at each layer:

• Physical Volume: Run pvs for a quick overview; use pvdisplay to inspect Physical Extent (PE) metrics.
• Volume Group: Run vgs to check free capacity (VFree); use vgdisplay to inspect the PE chunk size (defaults to 4MB).
• Logical Volume: Run lvs to check individual volume attributes; use lvdisplay to inspect detailed device mapper paths.

sudo vgs
sudo lvs

Verify the new size reported by the OS:

df -hT /mnt/data

The filesystem immediately reflects 35GB of available space without ever being unmounted.

Alerting best practices: Avoid monitoring disk usage percentages solely via df -h. With an LVM architecture, set up metrics tracking the Volume Group’s VFree field via Prometheus Node Exporter. When a VG’s spare capacity drops below 15%, triggering an early alert gives the SysAdmin team ample time to attach additional disks before production volumes reach a critical threshold.