LVM is the Logical Volume Manager for Linux, currently in version 2. It’s the new method to manage the disk storage in a way which is more flexible than the traditional disk partitioning. It allows you to create and modify volumes easily. The standard partitioning method has many limitations: when you shrink a partition which is at the end of your disk, you have to move the partitions if you want to reallocate this space to grow another partition. With LVM you don’t have such problems. All you need to use LVM is a Linux kernel with the device-mapper support enabled, and the lvm2 userspace tools. LVM2 has been in production for many years so it’s now very stable and you should not have any problems with it.
LVM comes with all the recent mainstream Linux distributions, and it’s even used by default on Redhat Linux. The purpose of this document is to help you to understand what it is, how it works, and to decide whether or not it’s good for you.
In the traditional partitioning layout, there are just two levels of storage: the physical disks, and the partitions which are containers inside a physical disk. LVM comes with three levels of storage to offer more flexibility. We end up with containers called Logical-Volumes which correspond to an improved type of disk partition. It’s important to understand that partitions and Logical-Volumes are just sets of disk blocks with a size. You still have to make a filesystem on your volume to use it. It’s different from Solaris ZFS where the volume manager and the filesystem are integrated. In the world of Linux, the volume manager and the filesystem are independent. You can choose which filesystem you want to use on the top of a Logical-Volume. The ext4 filesystem is the default choice because it is stable, but you can also use xfs for instance. In the future, btrfs could be the standard filesystem in Linux.
Here are the three levels of storage:
In any case all of these three levels are required. You have to create a Volume-Group even if you only have one Physical-Volume on your computer. With these three levels of storage, you can organize your data in a very flexible way, and you can sometimes make very interesting combinations.
LVM manages the disk space in chunks called extents. They all have the same size (32MB in general). That way the blocks of a volume can be spread over the whole size of your disks, which provides the possibility to resize the volumes multiple of times with no limitation other than the total disk space.
It’s also possible to use both LVM and the traditional partitioning method on the same disk: for instance you can install Windows on the first partition of your disk, install linux on the second partition, and create a third partition for LVM to store your data in a flexible way.
Let’s consider that you have two hard disks: /dev/sda (250GB) and /dev/sdb (160GB). Let’s create four primary partitions on the first disk for Linux-boot, Windows, Linux-root, and LVM, and one partition for linux on the second disk (entirely dedicated to LVM):
# parted /dev/sda parted> mklabel msdos parted> mkpart primary 0 100M parted> mkpart primary 100M 4196M parted> mkpart primary 4196M 8292M parted> mkpart primary 8292M 100% parted> quit # parted /dev/sdb parted> mklabel msdos parted> mkpart primary 0 100% parted> quit
The next thing to do is to create two Physical-Volumes on these disks. This will just initialize these two disks so that LVM can use them. There is no name associated with Physical-Volumes other than the name of the device where they have been created.
# pvcreate /dev/sda4 # pvcreate /dev/sdb1
Now, we will create one Volume-Group as the concatenation of the two Physical-Volumes. We have to choose a name for this Volume-Group, let’s use VolGroup00:
# vgcreate VolGroup00 /dev/sda4 /dev/sdb1
You can print details about this new Volume-Group using either vgdisplay or vgs.
This Volume-Group now provides about 400GB of storage that we can use to make Logical-Volumes. Each time we create a Logical-Volume we have to give it a name and a size. We could make one big Logical-Volume of 400GB is we wanted to, but let’s create only two Logical-Volumes and ext3 filesystems on the top:
# lvcreate -n data -L 50G VolGroup00 # mke2fs -j /dev/VolGroup00/data -L data # mount /dev/VolGroup00/data /mnt/data # lvcreate -n backup -L 35G VolGroup00 # mke2fs -j /dev/VolGroup00/backup -L backup # mount /dev/VolGroup00/backup /mnt/backup
When you use lvcreate, your system will create a special file to manage this device. It can be either /dev/vgname/lvname or /dev/mapper/vgname-pvname or both.
After some time, you may decide to use the disk space which is not yet allocated in your Volume-Group to grow a Logicial-Volume which needs more space. Most linux filesystems can be grown online, which means that you don’t have to unmount it. They can be grown even if they are in use. This is very useful on servers for which we want to avoid any down time. Let’s add 10GB of space for the backups:
# lvresize -L +10G /dev/VolGroup00/backup # resize2fs /dev/VolGroup00/backup
The command to resize a Logical-Volume is lvresize. You can either give it a relative size (+10 GB to grow it by 10GB) or an absolute size (45GB). When no size is given to resize2fs (the tool that resizes ext2/ext3/ext4 filesystems), then it automatically grows to the size of the underlying volume which is what we want. Be careful if you shrink a volume. You have to unmount the filesystem first since linux filesystems do not support online shrinking with the exception of btrfs. Also you have to shrink the filesystem first (using resize2fs, resize_reiserfs, …) and then you can resize the volume. A filesystem cannot be bigger than the volume where it lives. For this reason, it’s good practice not to allocate all the space of your Volume-Groups immediately. It’s recommended to create small Logical-Volumes first so as to leave some free space on your Volume-Group. You can always grow the volumes later when you need more space. This way you avoid having to unmount a filesystem to shrink it in order to free some space for other Logical-Volumes. This would require some down time which is not always possible on production machines.
There was a version 1 of LVM but it’s very old now so all the recent Linux
distributions have LVM2. By default lvm can be managed using the command line
tools which come with the package called lvm2. The names of these commands are
very easy to remember: in general there is a prefix which is one of the
following: pv, vg, lv depending on what sort of object we want to work on
(Physical-Volumes, Volume-Groups, Logical-Volumes). Then comes the name of the
action we want to perform: create, display, rename, reduce, … We end up with a
command such as
If these commands are not available and you are sure lvm2 is installed, you may
have to use one of these commands as an argument of the main lvm binary. So you
may have to type something such as
lvm lvcreate <arguments>
There is no real need for graphical tools with LVM because the physical way the blocks are stored does not really matter. With LVM we don’t have to know whether the volume is stored at the beginning or at the end of the disk: you can grow or shrink your volumes as long as there is some space somewhere in the Volume-Group. The lvm2 commands are really easy to use directly once you understand how they work. These commands accept the sizes in common units such as MB, GB, TB. You don’t have to worry about sectors or cylinders. Thereafter you just use the filesystem commands such as mkfs, fsck, resizefs on your volumes. There is no real need for graphical tools to do that either.
There are many good reasons to use LVM:
/dev/sdb1on another computer. This can break many things like the ability to boot. With LVM the Logical-Groups and the Logical-Volumes will keep the names they have been given even if the name of the physical disk is modified. You can rename them at anytime using commands such as
vgextend. Then use
pvmoveto move the extents of your Logical-Volumes from the old disk to the new one (they will stay inside the same Volume-Group). Then remove the old Physical-Volume from the Volume-Group using
vgreduce, and then destroy the old Physical-Volume. It’s a very useful technique to upgrade to a bigger hotplug hard-drive on a production server that must stay in production during the migration of the contents.
Despite these good things, LVM may not always be appropriate: