Nuts and Bolts LVM Basics Lead image: © Dvarg,
© Dvarg,

Introduction to LVM

APieceof the Pie

Fixed partitions on a Linux system can be created easily using tools such as fdisk, but the assignments tend to be wrong or the partitions too small at the worst possible moment. LVM requires slightly more effort at install time, but it soon pays dividends. By Charly K¸hnast

If a partition in a legacy partitioning system starts to run out of space, administrators have two options: They can mount another medium at a new mountpoint and accept the fact that they need to modify their paths or work with alias constructions, or they can replace the disk(s) with a larger model and restore a backup of the complete system to the new disk. This last approach means that the system is unavailable for an extended period of time, and the new disks could turn out to be too small at some point in the future.

The Logical Volume Manager (LVM) gives administrators an escape route by acting as an intermediate logical layer between the physical medium or partitions and the filesystem. Before I demonstrate the principle based on a hands-on example, I will look at the most important terms in the world of LVM [1] [2].

Physical volumes (PVs) are block devices (i.e., whole disk or partitions). To allow an LVM to use a PV, the LVM must be initialized using a command that I will show shortly. Doing this writes an LVM label and some metadata to the PV.

The PV is divided up into units of the same size (4MB by default) known as physical extents (PEs). A PE is the smallest allocatable data volume. Figure 1 illustrates the principle.

Physical and logical volumes are the elements that make up logical volumes. (Source: Blacknova/Wikipedia)
Figure 1: Physical and logical volumes are the elements that make up logical volumes. (Source: Blacknova/Wikipedia)

If one physical volume or multiple physical volumes exist, you can create a volume group (VG) from them. Again, this is made up of many smaller units, or logical extents. Within the volume group, the logical extents can point to physical extents that reside on different physical media – and this capability is definitive for the flexibility and attractiveness of LVM.

The volume group is the storage pool from which you will be drawing later when you create your logical volumes (LVs). A logical volume is formatted with a filesystem and then is available to the operating system. The commands for working with the three layers (PV, VG, and LV) are named consistently to reflect this schema; as in pvcreate, vgcreate, and lvcreate or pvscan, vgscan, and lvscan.

A Practical Example

The lab system has two hard disks (or SSDs, LVM doesn't mind which) of 100GB each. They are named /dev/sda and /dev/sdb. Three partitions exist on /dev/sda; the first of them, sda1, is used as the swap area and is just 5GB. The root filesystem (/) resides on sda2 and weighs in at 20GB. The remaining 75GB are assigned to the partition sda3. I will be using LVM to merge it with the whole of the second disk sdb. The logical volume of 175GB that this creates will be mounted as /backup.

Most important is that you don't have a filesystem on the disks or partitions that you want to use with LVM. If you do, you first need to remove that part using fdisk. Then, you can run pvcreate and create the partitions /dev/sda3 and /dev/sbd that you will use with LVM:

pvcreate /dev/sda3 /dev/sdb

If this works out, the system responds with:

Physical volume "/dev/sda3"
   successfully created
Physical volume "/dev/sdb"
   successfully created

If something goes wrong at this stage, it is almost always because a filesystem already exists in the partition. The pvscan command outputs a list of all physical volumes, as you can see in Listing 1.

Listing 1: pvscan

PV /dev/sda3                      lvm2 [74.59 GB]
PV /dev/sdb                       lvm2 [98.36 GB]
Total: 2 [172.85 GB] / in use: 0 [0   ] / in no VG: 2 [172.85 GB]

If you need more detail, you can use the pvdisplay command instead; this command gives you additional information about the number of physical extents, the amount of space occupied by the metadata, the UUID, and more.

The next step is to group the newly created physical volumes to create a volume group: The command for this is vgcreate:

vgcreate vg_backup /dev/sda3 /dev/sdb

The first parameter that vgcreate expects is the name of the volume group, which you can assign freely – at least to a certain extent. You will want to do without non-standard characters, although you can use hyphens and underscores. After the name comes the designators for the physical volumes that you will be adding to the new volume group, in arbitrary order.

Following the pattern established by the pvscan and pvdisplay commands that I just described, you can now run the vgscan and vgdisplay commands to display information about your volume groups.

In the space provided by the volume group, you can create one or more logical volumes – in the example here, I will be creating a single LV called lv_backup with a size of 170GB. I can't use all of the 175GB available because LVM needs some space for its management information.

lvcreate -L 170G -n lv_backup vg_backup

Of course, some helpers also provide information at this level: lvscan and lvdisplay. The final step is to create a firewall; in this example, I will use ext4:

mkfs -t ext4 /dev/vg_backup/lv_backup

Now you can mount and immediately start using the filesystem,

/dev/vg_backup/lv_backup /backup ext4 errors=remount-ro 0 1

but for it to survive a reboot, you should create an entry in /etc/fstab.

More Space!

Sooner or later, the 170GB space will be too small, and you will need to think about an extension. In this case, you can install another hard disk – about 500GB in this example – and use LVM to make the additional space available without any service interruptions.

Caution: The following steps have been tested in production and are normally unproblematic, but remember Murphy's Law. It's always a good idea to have a recent backup. And, you also need to initialize the new drive, /dev/sdc, for LVM:

pvcreate /dev/sdc

Next, you can add it to the existing volume group, vg_backup. The vgextend command does this for you:

vgextend vg_backup /dev/sdc

The command

vgdisplay -v vg_backup

lets you check to see that the volume group extension has worked, but the logical volume and the filesystem are still blissfully unaware of the changes. You can add the new storage space to the LV as follows:

lvextend -L 500G /dev/vg_backup/lv_backup

Finally, it's the filesystem's turn. Fortunately, most modern operating systems can be resized on the fly – for example, this command for ext4:

resize2fs /dev/vg_backup/lv_backup

If you enter this command without defining any other parameters, as in this example, it will resize the filesystem to the maximum size offered by the logical volume.


The example in this article shows how easy it is to create volumes with some help from LVM, and it demonstrates that resizing volumes on the fly is just as easy. This capability gives professional administrators the flexibility they need to cope with growing volumes of data on local storage or servers. In another article, I will be looking at snapshots on LVM. This feature gives administrators a great option for saving the current status of a volume of data.