Table of Contents
Introduction
Logical Volume Manager, or LVM, is a flexible layer that sits between your physical storage devices and the filesystems you use. Instead of creating filesystems directly on fixed-size partitions, you use LVM to create logical volumes that can grow, shrink, and be moved across disks with far more freedom than traditional partitioning allows.
This chapter focuses on the core concepts behind LVM, how its building blocks relate to each other, and why administrators use it in real systems. Details of actually creating and managing logical volumes are covered in later chapters that deal with practical storage management.
The Problem LVM Solves
Traditional disk partitioning creates fixed slices of a disk. You decide at installation time how big each partition should be, then you create filesystems on those partitions. If one partition becomes too small and another has plenty of free space, moving or resizing space between them is difficult, sometimes impossible without downtime or backup and restore.
LVM introduces an abstraction layer where space is pooled and then allocated dynamically. Instead of thinking "this filesystem lives on partition /dev/sda3", you think "this filesystem lives on logical volume lv_data, which draws space from a pool named vg_main, which in turn uses several physical devices." This indirection gives you flexibility that classic partitions lack.
Core LVM Building Blocks
LVM is built from several layers that stack on top of each other. From bottom to top they are physical volumes, volume groups, and logical volumes. Between volume groups and logical volumes LVM uses an internal unit called the physical extent.
Understanding the roles of each layer is essential before learning concrete commands, because practically all LVM operations manipulate these conceptual objects.
Physical Volumes (PV)
A physical volume is a storage device or a partition that has been prepared for use by LVM. It is the lowest LVM-aware layer above raw hardware. Typical examples of things that can become PVs include whole disks such as /dev/sdb, specific partitions such as /dev/sdb2, or even software RAID devices such as /dev/md0.
When you convert a device into a physical volume, LVM writes metadata on it to record that it belongs to LVM and to track its participation in higher-level structures. The remaining space on that device is divided into chunks that LVM calls physical extents. These extents are the allocation units used for logical volumes.
A device that is part of LVM is no longer used directly by filesystems. Instead, LVM manages it and provides logical volumes on top.
Volume Groups (VG)
A volume group is a storage pool created from one or more physical volumes. Conceptually, a volume group is to physical volumes what a virtual disk is to physical disks. Once you have a volume group, you create logical volumes inside it.
If you have several disks and you turn each into a physical volume, you can combine them into a single volume group. LVM then treats all extents in that group as a single pool of free and used space. Logical volumes consume extents from this common pool.
Because a volume group can span multiple physical volumes, you can expand the available space for all logical volumes in that group by simply adding a new physical volume and assigning it to the volume group. The logical volumes do not need to know, and often do not care, which physical disk their extents actually live on.
Physical Extents (PE)
Inside a volume group, space is divided into small, equal-sized blocks called physical extents. An extent might be 4 MiB, 8 MiB, 16 MiB, or another size chosen when the volume group is created. Every physical volume that is part of that volume group uses the same extent size.
Logical volumes are built as sequences of logical extents, and there is a one-to-one mapping between logical extents and physical extents. This mapping is how LVM knows which parts of which disks store each part of a logical volume.
For example, suppose a volume group uses an extent size of 4 MiB. A logical volume of size 20 GiB will consist of a certain number of logical extents. The total size of that volume is:
$$
\text{Size} = \text{Number of extents} \times \text{Extent size}
$$
If the extent size is $4\,\text{MiB}$ and the volume has $5120$ extents, then:
$$
\text{Size} = 5120 \times 4\,\text{MiB} = 20480\,\text{MiB} = 20\,\text{GiB}
$$
In LVM, logical volume size is always an integer multiple of the extent size. The extent size chosen when creating a volume group cannot easily be changed later, so it affects how finely you can adjust logical volume sizes.
Logical Volumes (LV)
A logical volume is where you put your filesystem or other data format, such as a swap area. To the operating system, a logical volume looks like a regular block device, similar to /dev/sda3. You can create a filesystem on a logical volume, mount it, and use it like any other storage device.
The important difference is that logical volumes are not fixed partitions. Since they are sequences of logical extents, and those map to physical extents spread across one or more physical volumes, LVM can change that mapping over time. LVM can add more extents to a volume, remove some, or move them between physical volumes, often while the filesystem is still mounted.
Standard practice is to name logical volumes in a way that hints at their purpose, such as lv_root, lv_home, or lv_data. Device files for logical volumes usually appear under /dev/<vg_name>/<lv_name> or /dev/mapper/<vg_name>-<lv_name>.
LVM Abstraction Stack
The relationships between the concepts can be summarized as a stack. At the bottom you have hardware or virtual block devices. On top of that you have physical volumes, grouped into volume groups that form storage pools. Then you have logical volumes created out of those pools, and finally filesystems:
Hardware or virtual devices → Physical volumes → Volume groups → Logical volumes → Filesystems and applications.
This stack is critical to understand, because many LVM operations simply move or reshape how extents are allocated within that stack. For example, extending a logical volume by adding extents is fundamentally just a change in the mapping between logical extents and physical extents.
Advantages of Using LVM
LVM provides a variety of capabilities that traditional partitions cannot match in a convenient way. The most important advantages are flexible allocation, storage pooling, and easier disk management across time.
One key benefit is the ability to resize logical volumes. If you sized /home too small, you can extend the logical volume that holds it, provided the volume group has free extents or you can add another physical volume. In many cases, and with a filesystem that supports online resizing, you can do this without unmounting.
Another advantage is that volume groups pool space from several disks. Rather than managing separate isolated partitions on separate disks, you have a single pool of space. This often leads to better utilization, since free space on one disk can help volumes that grew from another. It also simplifies growth. If your pool is running low on space, you add another disk, turn it into a physical volume, and add it to the group.
LVM also supports moving data between physical volumes. If you want to retire a disk or replace it with a larger one, LVM can migrate extents from the old physical volume to a new one. Once everything is moved, the old disk can be removed from the system without reformatting or moving files manually at the filesystem level.
On top of these, LVM supports snapshots, thin provisioning, and other advanced features. These depend on the core concepts described here, but the features themselves are covered separately.
LVM and Device Types
LVM does not require raw physical disks. It operates on any block device, which may be physical hardware or a layer built from multiple devices.
You can, for instance, build software RAID with a tool like mdadm, which produces a device such as /dev/md0. You can then turn /dev/md0 into a physical volume and include it in a volume group. LVM then allocates extents on top of that RAID device. This lets you combine resilience or performance from RAID with flexibility from LVM.
In virtualized environments, the "physical" volumes are typically virtual disks provided by the hypervisor. The LVM stack remains the same, even if the bottom layer is a file-backed virtual disk in a cloud provider or on a local hypervisor.
Metadata and LVM Internals
LVM maintains metadata describing how logical volumes map to physical extents and which physical volumes belong to which volume groups. This metadata is critical. It tells LVM which blocks of which disks contain which parts of each logical volume.
The metadata is stored on physical volumes themselves and often also cached under /etc/lvm. Because metadata is replicated among volumes in a volume group, LVM can usually tolerate the loss of a single device from a metadata point of view, though data resilience is a separate problem handled by other technologies such as RAID.
The use of extent mappings means that logical volumes do not have to occupy contiguous regions on a disk. A single logical volume may consist of extents scattered across several disks. LVM hides this from the filesystem, which only sees a flat address space.
Planning LVM Layouts
Since LVM introduces a flexible abstraction, it encourages a planning mindset that is different from traditional partitioning. Instead of deciding final sizes at installation, you usually create a volume group with most of the available disk space and then allocate logical volumes somewhat conservatively, leaving unallocated free space in the group for future growth.
You typically decide which parts of the system deserve their own logical volumes. Common candidates are the root filesystem, home directories, application data, database storage, and sometimes separate volumes for logs or temporary data. Each logical volume can later be extended or shrunk, subject to filesystem support and available free extents in the group.
It is also common to think about how volume groups map to physical disks. For example, you might keep one volume group for system data on fast SSDs and another for archival data on slower spinning disks. Understanding that a volume group defines the physical characteristics of the pool, while logical volumes define how you slice that pool for different uses, is central to planning.
Extent Allocation and Performance
Since LVM allocates whole extents, the pattern of allocation can affect performance characteristics. Depending on how you create and extend logical volumes, extents for a given volume might end up clustered on one physical volume or spread across several.
If a volume spans multiple disks without RAID, LVM will, by default, allocate extents sequentially on one disk and then on another, rather than in parallel stripes. This means that spreading a logical volume across disks in a naive way does not automatically produce the kind of performance that striped RAID offers. Instead, it simply allows the logical volume to grow beyond the capacity of a single disk.
There are LVM segment types, such as striped volumes and mirrors, that control how extents are distributed, but those represent additional concepts beyond the basic LVM core and are discussed separately. At the conceptual level, it is enough to understand that LVM can map extents flexibly, and that this mapping is what determines how a logical volume uses your hardware.
Snapshots and Thin Provisioning as Concepts
LVM supports storing point-in-time snapshots of logical volumes. Conceptually, a snapshot is a special logical volume that records changes relative to an original volume. At the time of creation, the snapshot represents the same data, then as data changes on the original, LVM copies old blocks into the snapshot so that the snapshot still shows the earlier state.
Thin provisioning extends the flexible allocation model further by allowing logical volumes to appear larger than the physical extents currently allocated. In a thin pool, LVM allocates space as data is actually written, not when the logical volume is created. This is a conceptual step beyond basic LVM, built on the same ideas of extents and flexible mapping.
Details of how to create and manage snapshots and thin volumes belong to more advanced topics. You only need to understand at this point that they are further uses of the same underlying concepts of pooled extents and logical to physical mapping.
LVM and Traditional Partitions
In many systems, especially those installed by distribution installers, LVM coexists with traditional partitions. For example, a common layout is to create a small separate partition for /boot outside LVM, and then use the rest of the disk for an LVM physical volume. The volume group inside then holds logical volumes for root, home, and other data.
From a conceptual point of view, the presence of a traditional partition table is orthogonal to LVM. Partition entries simply identify segments of a disk. Those segments can be used directly or assigned to LVM as physical volumes. Once inside LVM, the concepts of PV, VG, LV, and PE are the same regardless of how the underlying block devices are created.
Conceptual Workflow with LVM
To tie the concepts together, consider the typical order in which an administrator would reason about storage using LVM, focusing only on the conceptual steps and not specific commands.
First, hardware or virtual disks are identified. Then certain disks or partitions are designated for LVM usage and turned into physical volumes. Next, one or more volume groups are created, each combining one or more physical volumes into a pool. Inside each volume group, logical volumes are created for specific purposes, such as system partitions or application data stores. Finally, filesystems or other structures, such as swap, are created within those logical volumes and mounted where appropriate.
As the system evolves, additional disks can be introduced as new physical volumes and added to existing volume groups. Logical volumes can be extended into the new space. Data can be moved between physical volumes without changing mount points or filesystem configuration, because the abstraction is preserved.
Summary
LVM replaces rigid partition boundaries with a layered model of pooled and flexible storage. Physical volumes supply raw space, volume groups pool that space, physical extents slice it into manageable blocks, and logical volumes allocate those blocks to real uses.
By seeing storage through these concepts rather than through fixed partitions, you gain room to grow, shrink, move, and protect data in ways that would be far more disruptive otherwise. Later chapters build on these ideas to show practical LVM commands and advanced features, but all of that rests on understanding the conceptual model described here.