CentOS 7 uses the Logical Volume Manager (LVM) to organize the structure and available capacity of your partitions. It is a very dynamic and flexible system that can be extended or rearranged over time, and which is essential in today's most demanding and ever-changing environments. At the moment, buzzwords such as big data or cloud computing can be heard everywhere. Since massive amounts of data get produced all the time, storage requirements and disk space have to grow at the same steady pace. In this recipe, you will learn how to work with the LVM system and how to extend your physical drives, and also how to shrink and extend the capacity of your filesystems.
To complete this recipe, you will require a working installation of the CentOS 7 operating system with root privileges. We will use virtual block devices instead of real disk devices to show you from scratch how to set up a LVM first, and afterwards how to work with it. Please read the Creating a virtual block device recipe and create three 1 gigabyte virtual block devices with the GPT partition table, which will be labeled as /dev/loop0
, /dev/loop1
, and /dev/loop2
in this example.
Again, feel free to use real disk devices if you feel ready for it.
First, we will start by creating an LVM test environment similar to the standard CentOS 7 LVM structure, which is set up during the installation of every server system:
root
and show information about our virtual block devices:lsblk -io NAME,SIZE
parted -a optimal /dev/loop0 mkpart primary 2048KiB 100% parted -a optimal /dev/loop1 mkpart primary 2048KiB 100% parted -a optimal /dev/loop2 mkpart primary 2048KiB 100%
yes
to remove the gpt
label):pvcreate /dev/loop0p1 pvcreate /dev/loop1p1 pvcreate /dev/loop2p1
pvdisplay
vgcreate myVG1 /dev/loop0p1
vgdisplay myVG1
lvcreate -L 10m -n swap myVG1 lvcreate -L 100m -n home myVG1 lvcreate -L 400m -n root myVG1
lvdisplay myVG1
Free PE / Size
in the output):vgdisplay myVG1
mkswap /dev/myVG1/swap mkfs.xfs /dev/myVG1/home mkfs.xfs /dev/myVG1/root
root
partition, which is currently 400
megabytes (M
) in size, by 200
megabytes, and afterwards, let's increase the home
partition by 500
megabytes (confirm the possible data loss):lvresize -L -200m /dev/myVG1/root lvresize -L +500m /dev/myVG1/home
vgdisplay myVG1
again to see how the volume group's free space changes by running the previous commands (see Free PE / Size
).mkdir /media/home-test;mount /dev/myVG1/home /media/home-test xfs_growfs /dev/myVG1/home
G
), but you only have 184.00 MiB left on the underlying volume group. First, we need to add our two prepared physical volumes from the beginning of this recipe to our volume group:vgextend myVG1 /dev/loop1p1 /dev/loop2p1 vgdisplay myVG1
Free PE / Size
) to expand our home logical volume (the volume must stay mounted):lvresize -L +1500m /dev/myVG1/home xfs_growfs /dev/myVG1/home
Here, in this recipe, we have shown you how to work with the LVM for XFS partitions. It has been developed with the purpose of managing disk space on several hard disks dynamically. You can easily merge many physical hard disks together to make them appear as a single virtual hard disk to the system. This makes it a flexible and very scalable system in comparison to working with plain old static partitions. Traditional partitions are bound to, and cannot grow over, the total disk capacity they reside on, and their static partition layout cannot be changed easily. Also, we have introduced some important LVM technical terms that provide different abstraction layers to a hard disk, and which will be explained in this section so as to understand the concepts behind it: physical volume (pv), volume group (vg), and logical volume (lv).
So, what did we learn from this experience?
We started this recipe by creating three virtual block devices of 1 gigabyte (G
) each and then one partition spanning the whole device on each of them. Afterwards, we defined these single-partition devices as physical volumes (pv) using the pvcreate
command. A pv is an LVM term that defines a storage unit in the LVM world. It must be defined on a partition, full drive, or loop device. A pv is just an abstraction of all the space available in the surrounding partition so that we can work with it on an LVM basis. Next, we created a volume group (vg) with the vgcreate
command, where we also had to define a volume group name of our choice and put the first pv in it as a basic storage volume. As you can see, a vg is a container for at least one pv (we add more pv's later). Adding or removing pv's to or from a vg is the heart of the whole scalability concept of the LVM system. The pv's don't have to be all the same size, and it is possible to grow your vg over time by adding dozens of new physical drives all defined as pv. You can have more than one vg on your system, and you can identify them by the unique names you are giving to them. So, in summary, to extend the space of your vg, you have to create pv's out of physical drives, which you can then add to.
Finally, we created logical volumes (lv) on our vg, which can be seen and used like real physical partitions within a vg. Here, we created three lv's using the lvcreate
command, by which we need to define the name of the vg (remember, there can be more than one vg on your system) that we want to put our target lv on, along with the size of the volume, as well as a name for it as the last parameter. You can add multiple lvs into a vg and you don't need to use the whole allocated space from the underlying free space of the vg. You can be very flexible with it. The best part is that your decision about your volumes' size and layout doesn't have to be fixed for all time; you can change them anytime later. It is a very dynamic system that can be extended and shrunk, deleted and created, without having to unmount the volume beforehand. But you have to remember that all lvs are bound to a vg, and it is not possible to create them without it or outside its spacial boundaries. If you need to extend an lv's space over the borders of the underlying vg, you have to extend the vg, as show in this recipe.
After you have successfully created your lv's, you can work with them as you would with every other block device partition on your system. The only difference is that they reside in special device folders: /dev/<vg name>/<lv name>
or /dev/mapper/<vg name>/<lv name>
. For example, the home volume created in this example has the name /dev/myVG1/home
. Finally, in order to use them as normal mount points, we created some test filesystems on them.
In the second part of this recipe, we showed you how to extend our vg and how to shrink and expand our lv's test system.
We started by using the vgdisplay myVG1
command to show the currently available space on the vg. In the command output, we saw that our current volume group has a total of 996M
(VG Size
), the allocated size from our lv's (swap
, home
, root
) is 512M
(Alloc PE / Size
), and the free size is 484M
(Free PE /Size
). Next, we used the lvresize
command to shrink and expand the logical volume's root and home. The -L
parameter sets the new size of the volume, and with the +
or -
sign, the value is added to or subtracted from the actual size of the logical volume. Without it, the value is taken as an absolute one. Remember that we could only increase the home partition because the current volume layout does not occupy the complete vg's total space. After resizing, if we use the vgdisplay
command again, we see that we now occupy more space in the vg; its free size has been decreased to 184M
. Since we expanded the home
volume from 100M
to 500M
in total, we need to remember to expand its XFS filesystem too, since expanding a volume does not automatically expand its filesystem. Therefore, 400M
of the current volume are unallocated without any filesystem information. We used the command, xfs_growfs
, which will, without defining a limit parameter, use the complete unallocated area for the XFS filesystem. If you want to resize any other filesystem type, such as ext4, you would use the resize2fs
command instead.
Finally, we wanted to grow the home volume by 1.5G
, but we only have 184M
left on our vg to expand. This is where LVM really shines, because we can just add some more physical volumes to it (in the real world, you would just install new hard disks in your server and use them as pvs). We showed you how to extend the capacity of your vg by adding two 1G-sized pvs to it using the vgextend
command. Afterwards, we used vgdisplay
to see that our vg has now grown to 3G in total size, so finally we could extend our home lv as it would now fit into it. As a last step, we expanded the XFS file system once again to fill up the whole 2G home volume size.
Please remember, all the time, that if you use vg's with several physical hard disks, your data will be distributed among these. An LVM is not a RAID system and has no redundancy, so if one hard disk fails, your complete vg will fail too and your data will be lost! In order to deal with this problem, a proposed solution could be to use a physical RAID system for your hard disks and create an LVM on top of that.