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  .
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.
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
A Practical Example
The lab system has two hard disks (or SSDs, LVM doesn't mind which) of 100GB each. They are named
/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
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/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
§§noumber 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 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
pvdisplay commands that I just described, you can now run the
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:
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
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:
Next, you can add it to the existing volume group,
vgextend command does this for you:
vgextend vg_backup /dev/sdc
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:
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.