LVM (Logical Volume Manager) Tutorial on Linux

Working with storage in Linux without racking your brain over classic partitions is possible thanks to LVM (Logical Volume Manager)This system adds a layer of abstraction on top of the physical disks that allows you to resize, move and protect data with a flexibility that, in professional environments, makes the difference between having to shut down a server or being able to do everything on the fly.

If you manage systems or are preparing for certifications like LPIC, RHCSA, or similar, a solid understanding of LVM is no longer optional. Throughout this tutorial, we will see... What is LVM, how is it structured, how to create and manage PV, VG and LVIn addition to delving into real-world operations: scale-ups, scale-downs, mirrors, snapshots, migrations between storage arrays, use of extended LUNs, and solving typical problems you might encounter in production.

What is LVM and why is it used in Linux?

When we talk about LVM, we are referring to a system that allows manage storage logically instead of relying directly on fixed partitionsInstead of having a 50 GB /dev/sdb1 and a 100 GB /dev/sdc1 used separately, LVM allows you to group them into a single space by combining their capacity to form what is known as a pool volume or Volume Group (VG) of 150 GB.

On top of that VG we can define several logical volumes (LVs), for example, one of 20 GB for /opt, another of 100 GB for /var, and another of 30 GB for backups. This abstraction layer makes it possible redistribute space much more easily than with traditional partitioningwhere once the partition size has been created, changing it is delicate or simply impossible while hot.

One of the great advantages of LVM is that it allows us to create snapshots of a logical volume to have a quick restore point, expand file systems on the fly by adding new disks to the VG, or move data from one disk to another within the same group without stopping services. In environments with disk arrays, SANs, or shared storage, this ability to migrate data between disks or arrays without downtime is invaluable.

In the real world, this translates to you being able to moving a database from a congested server room to a faster one without users noticing anything beyond some extra I/O load, or being able to grow an application filesystem because it has fallen short, without restarting the server or manually touching services.

Basic LVM structure: PV, VG, and LV

To fully understand LVM, you need to be clear about its main components, which form a hierarchy from the most physical to the most logical. The key is that Each level builds upon the previous one to provide flexibility. without the file system needing to know all the details of the hardware.

At the base of it all are the Physical Volume (PV)These are simply physical disks, partitions (for example, /dev/sdb1, /dev/sdc1), storage array LUNs, or even software RAID devices like /dev/md0. Each PV is internally divided into fixed units called Physical Extents (PE)which will be the pieces with which the logical volumes will be constructed.

Above the PV we have the Volume Group (VG)Volume Groups (VGs) group one or more physical volumes to form a storage pool. The size of a VG is the sum of the capacity of all the PVs that comprise it, minus the space already allocated to logical volumes. In practice, the VG is the "container" from which we will extract space to create custom LVs.

At the bottom of the ladder are the Logical Volume (LV)These are the volumes that the system sees almost as if they were normal partitions. It is on an LV that we create the file system (ext4, xfs, etc.) and mount it at /, /var, /home, or wherever we need. Internally, each LV consists of Logical Extents (LE)which are mapped 1:1 with the PEs of the VG, but can be spread across several physical disks without being contiguous.

The kernel uses the device mapper to translate these logical devices (/dev/mapper/vg00-rootvol, for example) to the corresponding physical blocks. LVM's user-friendly names are usually symbolic links to devices like /dev/dm-0, /dev/dm-1, etc., allowing for enormous flexibility when combining disks, RAID, encryption, and LVM without the upper layers noticing.

In a real system, if we execute commands like vgs, pvs and lvs We will be able to see the list of existing volume groups, physical volumes, and logical volumes, their total size and free space, as well as activation attributes, status, UUID, etc. With vgdisplay -v We can get even more detail: number of LVs, size of PE, number of free PEs, list of PVs that form the group, etc.

Visualize the existing LVM structure in the system

Before touching anything, it is essential to know What LVM structure do we currently have in the system?To do this, three main summary commands are used: pvs, vgs, and lvs. Each one shows a different and complementary view of the same reality.

If we want see which disks or partitions belong to each group, we use pvsThis command will display the device paths (for example, /dev/sda2, /dev/sdb1, /dev/sdc1), the VG they belong to, the PV size, and how much unallocated space is still available on each. It is very useful for verifying that a new disk has been correctly added to a VG.

With the command vgs We will obtain a list of all volume groups, indicating how many PVs, LVs, and snapshots (SNs) each contains, as well as the total group size and available free space. This allows us to quickly identify which groups are fullest and where we have room for expansion.

Finally, with lvs We will see the list of logical volumes, with information such as size, the VG they belong to, attributes (for example, whether they are mirrors, snapshots, thin, etc.), usage percentage in the case of snapshots, and other key data. On servers with many LVs, this command becomes almost indispensable for keeping track of the different filesystems.

If we want an even more detailed report on a specific group, we can run vgdisplay -v NameVGThis command will display the VG configuration, all its LVs with extended information, and finally, the details of each PV that comprises it. It is especially useful for diagnostic or storage auditing tasks.

On the other hand, if we inspect the file systems mounted with mount o df -hWe will see that the assembly points point to routes under /dev/mapper/VG-LVFor example, /dev/mapper/vg00-rootvol mounted on /, /dev/mapper/vg00-varvol on /var, etc. This confirms that filesystems are indeed supported on LVM logical volumes.

Creating an LVM structure from scratch

To set up a new LVM structure, we start with one or more free disks (or partitions). The typical workflow consists of: create a PV, then a VG, and finally one or more LVs about which forma tear file systems.

Initialize a Physical Volume (PV)

The first step is to mark a disk or partition as a physical volume for LVM using the command pvcreateThis initializes the metadata necessary for LVM to manage it. For example, if we want to use /dev/sdb as a PV, we would run:

pvcreate /dev/sdb

After this step, that device becomes capable to integrate into a group of volumesIn some distributions like Red Hat, when you create a VG from scratch, the installer already performs pvcreate automatically, but knowing the command is essential for manual extensions and configurations.

Create a Volume Group (VG)

With the PVs ready, we define the volume group with the command vgcreateThis command takes the name of the VG and the list of physical devices that will comprise it. For example, to create a VG called vgMySQL with two disks:

vgcreate vgMySQL /dev/sdb /dev/sdc

From that moment on, vgMySQL will be a storage pool on which we can create one or more logical volumes for different uses (data, logs, backups, etc.). We can check the result with vgdisplay vgMySQL or with the short summary vgs.

Define Logical Volumes (LV)

Once the volume group is created, the next step is reserve space within that group for each LVWe do this with the lvcreate command, specifying the name, size, and VG. A simple example would be:

lvcreate -n lvMySQL -L 10G vgMySQL

That command will create a 10 GB logical volume within vgMySQL, which will appear as /dev/vgMySQL/lvMySQL (and also as /dev/mapper/vgMySQL-lvMySQL). From here on, we will treat it almost as if it were a traditional partition on which to create a filesystem.

Create the file system on the LV

With the LV created, all that remains is format it with the type of file system that best suits our needsFor example, if we want to use XFS on the logical volume for the database:

mkfs.xfs /dev/vgMySQL/lvMySQL

Next, we will create the mount point (for example, /Backup_MySQL, /data_mysql, etc.) and add the corresponding entry in / etc / fstab so that it mounts automatically at startup. From then on, applications will only see a normal filesystem, even though LVM is being used underneath.

Merge two volume groups (vgmerge)

Sometimes we may want merge two VGs into one To simplify management or to easily reallocate space between logical volumes that were previously in separate groups, the `vgmerge` command exists, which combines the second group into the first.

Before merging, it's important to make sure that There should be no duplicate LV names between both groups and that the size of the extents (PE) is the same in both VGs, otherwise the command will fail or require prior adjustment steps.

The typical procedure includes unmount the affected filesystemsDeactivate the VG you want to integrate and run vgmerge. For example, to merge vgPostreSQL into vgMySQL:

vgchange -an vgPostreSQL
vgmerge vgMySQL vgPostreSQL

After the merger, all LVs that belonged to vgPostreSQL will become part of vgMySQLand we can reactivate and mount them normally. This type of operation is useful when reorganizing server storage in the medium or long term.

Essential commands for managing LVM

In addition to creating PV, VG and LV, in the day-to-day administration it is essential to know increase, decrease, delete and move volumes without compromising data. LVM offers a wide range of commands that are worth mastering, both in their basic form and in advanced scenarios.

Extending a filesystem in LVM

One of the most frequent tasks is when a filesystem runs out of space and we need increase the size of the LV and the file systemThe general workflow in ext3/ext4 file systems is usually to use lvextend for the logical volume and then the FS growth tool, such as resize2fs.

For example, to reduce a volume to a total size of 512 MB, we could run:

lvextend -L 512M /dev/VolGroup00/LogVol02
resize2fs /dev/VolGroup00/LogVol02

If instead what we want is add additional space to the current size (for example, to grow by 512 MB from what the LV already has), we use the syntax with the plus sign:

lvextend -L+512M /dev/VolGroup00/LogVol02

In systems with XFS, filesystem growth is done with xfs_growfs pointing to the mount point or device. It is important to know the correct tool for each type of file system, as they do not all behave the same way with upgrades.

Reducing the size of a filesystem and an LV

The opposite operation, reducing, is more delicate because it involves shrink the file system and then the LVNot all filesystems allow it: EXT4 does support shrinking, while XFS, for example, does not support shrinking, only growing.

A typical workflow with ext4 involves first shrinking the filesystem (usually after unmounting it and running fsck if the tool requires it) and then using lvreduce to adjust the logical volume size. Many distributions facilitate this with the option -r in lvreduce, which coordinates both steps more securely:

lvreduce -r -L95G /dev/mapper/vgdml-lvdml

The process itself will perform integrity checks, adjust the filesystem size, and finally reduce the LV to the specified value. Even so, it's prudent to have always back up when reductions are made, since an error at this point can be critical.

Delete a logical volume

To delete a LV that we no longer need, we must make sure that not mounted or in useOnce the filesystem is unmounted, we can delete the logical volume with lvremove:

lvremove /dev/VolGroup00/LogVol02

This command removes the LV definition and releases its extents within the VGso that this space will be available to create other volumes or to expand existing ones within the same group.

Creating and managing mirrors with LVM

If we don't have a RAID per controller in the hardware, we can configure mirrors at LVM levelThis works provided the VG has enough space and the physical disks are properly distributed. Older versions used `lvextend` with the `-m` option, but newer versions use `lvconvert`.

To create a mirror of an existing LV, we specify the number of copies (m1 (means a mirror copy in addition to the original):

lvconvert -m1 /dev/VolGroup00/LogVol02 /dev/sdae

During the process, LVM synchronizes both copies and we can observe the progress with lvs, seeing how the synchronization percentage It goes from 0 to 100. If at any point we want to return to linear mode (without mirroring), we can use lvconvert with -m0 to remove the mirror.

In a typical practical example, a new VG is created with two disks, and a LV in mirror mode and it is formatted. After copying data to the filesystem (for example, a large ISO installation DVD to test integrity), you can verify that synchronization has finished and that both disks contain the same contents.

Another interesting situation is when we want break the mirror to remove a disk (for example, to replace it with another). First, we convert the LV to linear mode with lvconvert -m0, which allows us to one of the VG disks is left free of dataNext, we run `vgreduce` to remove that PV from the group, and finally, we can recycle or physically remove the disk. Later, we can add a new drive with `vgextend` and redo the mirror with `lvconvert -m1`.

Moving data between disks within the same VG (pvmove)

In large business environments it is common that, with ThereSome disk arrays may become slow or overloaded. LVM provides the command pvmove To move data from an old PV to a new one within the same VG without stopping services, copying extents from one disk to another transparently.

The typical workflow would be to first add the new fast disks to the VG with vgextendso that we can see both the old and new ones in pvs. Then we run pvmove specifying the origin and destination, for example:

pvmove /dev/sdg1 /dev/sdk1

As it runs, pvmove displays the percentage completed. It's an I/O-intensive process that should be scheduled outside of peak hours, because It will read from the old disk, write to the new one, and erase the old data.Once finished and verified that there is no more data left in the old PV, we can remove it from the group with vgreduce so as not to use that slow booth again.

Activate and deactivate volume groups (vgchange)

In high-availability configurations, especially in clusters, it is common for The VGs are activated and deactivated on different nodes depending on where the service is running. Although this is usually managed by the cluster software, sometimes it has to be done manually.

To mark a VG as active (available to mount your LVs) we use:

vgchange -a y NombreVG

And to disable it, for example before migrating a volume to another server, the following are used:

vgchange -a n NombreVG

Combined with vgscanBy forcing the system to scan devices to find LVM structures, we can make another node in the cluster recognize and activate the same groups that have been created or modified in the first one.

Snapshots in LVM: creating, restoring, and deleting

One of LVM's most powerful features is its ability to create snapshots of logical volumesA snapshot captures the state of a live server at a given moment and is stored in an additional storage area where subsequent changes are recorded. This allows you to roll back the changes if an update or configuration change goes wrong.

The basic flow would be: create a file or dataset in the source filesystem, generate the snapshot with lvcreate using the option -sMake additional changes and, if something fails, unmount the FS and merge the snapshot with lvconvert –merge to restore the previous state.

For example, to create a 100 MB snapshot of /dev/vgtest/lvtest we could run:

lvcreate -s -n lvtest_snapshot -L 100M /dev/vgtest/lvtest

As long as the snapshot exists, LVM will continue to save the modified blocks with respect to the original. If we want to "undo" changes made to the filesystem after creating the snapshot, we unmount the volume, run `lvconvert --merge` on the snapshot, and remount the filesystem. The files they will return to the state they had at the time of creating the snapshot.

If, on the other hand, we verify that everything is working correctly and we want to make the changes permanent, we simply delete the snapshot with lv removeThis way we free up the space that was reserved in the VG and prevent it from filling up due to excessive changes.

Key LVM Tools and Commands

LVM2, the version used in modern kernels, offers a wide range of specialized commands. Although we've already mentioned some, it's helpful to have an overview of the most important tools for manage the complete lifecycle of the volumes.

• pvcreate, vgcreate, lvcreateThey create physical, group, and logical volumes.
• pvdisplay, vgdisplay, lvdisplay: They show detailed information about each type of LVM object.
• pvs, vgs, lvsThey provide a very useful summary view to get a quick snapshot of the storage status.
• lvextend, vgextend: They expand logical volumes or groups by adding size or new PVs.
• lvreduce, vgreduce: reduce the size of LVs or remove PV from a VG.
• pvscan, vgscan, lvscanThey scan the system for LVM structures.
• pvchange, vgchange, lvchange: modify attributes (for example, activation, permissions) of the different elements.
• pvmove: migrates data from one physical volume to another within the same VG.
• pvresize, lvresizeThey adjust the data structure to be able to grow or shrink volumes.
• vgcfgbackup, vgcfgrestore: They store and restore VG metadata.
• vgconvert: changes the metadata format, useful for migrating between LVM versions.
• lvconvert: converts volumes between linear, mirror, snapshot, etc. modes.
• vgexport, vgimport, vgimportcloneThey export/import VGs to move them to other systems, avoiding name conflicts.
• vgmerge, vgsplit: allow merging or splitting groups of volumes.
• vgrename, lvrename: change the name of VGs and LVs without affecting the data.
• pvremove, lvremove: They remove PVs from LVM and delete LVs that are no longer in use.

Having a certain mastery of this set of tools makes working with storage in Linux something much more malleable and less traumaticallowing for profound changes without interrupting services and facilitating long-term maintenance.

Mastering LVM involves a thorough understanding of its PV-VG-LV structure, how it interacts with file systems, and fluency in commands such as pvcreate, vgcreate, lvcreate, pvmove, lvextend, and snapshots; with this foundation, any administrator can manage Linux server storage. with much greater security and flexibility than with traditional partitioning.