Logical Volume Manager (LVM) explained

May 5, 2011 at 7:22 PM - by Freek Lijten - 2 comments

Tags: linux, virtualization, LVM

As an example in this article I use the setup of our backup server called storage. At the bottom of this all there's a Physical Volume (PV) which for instance can be a HDD, a partition or as mentioned above a RAID setup. In the case of storage there are two PVs of 2.73TB each.

Typical volume management will treat these PVs as a series of blocks called Physical Extents (PEs). PEs can differ in size, but whatever the size, it means we have N blocks of PEs at a combined size of 2.73TB per PV. One or more of these PEs map to one Logical Extent (LE). If data is written to a LE which maps to two PEs, the data is duplicated, thus creating the same effect as a RAID1 setup. Most of the times however one LE will map directly to one PE. On the LVM setup of storage all these LEs (of both PVs) are aggregated into a single Volume Group (VG).

Fig.1: Storage server with PVs, PEs, and LEs combined into a volume group

There are a lot of words and terms flying around now so lets summarize it a bit. We have one or more Physical Volumes which are devided into PEs which map to LEs. A Volume Group can perfectly span more than one PV. Lets assume there is only one VG on our server. This VG is made up of all the LEs of all the PVs on that server. So basically we have one enormous basket of LEs. 

A VG however can not be used as you would a partition in a non LVM-system yet. You first need to create a Logical Volume (LV) inside the VG. This LV will act as if it was a partition. On our storage server there's exactly one LV, sized 5.46TB. So what have we achieved here? First of all there's one large partition instead of two seperate disks. Secondly it is very easy to add another PV of 2.73TB (or of any other size for that matter). Simply add the disk, enlarge the volume group and after that the logical volume. The servers storage is now much larger without any downtime.

Fig. 2: Showing a Logical volume on top of a volume group

Splitting it all up again

I just described the process of aggregating all the space on several PVs into one large VG. For our storage machine this works perfectly well, but for our machines which host various virtual servers, there's another step to be taken. Its time to devide all that space up again. So instead of one huge logical volume, we create multiple smaller LVs. Each LV can then be the "disk" of a virtual server.

This way some servers house up to 10 virtual servers on there respective logical volume. A nice extra feature of LVM is the ability to give the LVs sensible names. This ways the LVs can be addressed as v001 and v006 instead of sda, sdb, etc.

Fig. 3: Logical volumes on top of a volume group

A word of warning

So are there no drawbacks to the LVM? Not if you setup your system well, but you have to take a risk into account. If you have a lot of PVs, which are single HDDs, with even more LVs spread out over them you run the risk of loosing all these LVs to a single PV failure. The least you should do is make sure your PVs are the result of some RAID setup. That way, if one of the disks in the RAID setup fails, you have a backup.

I think this is enough information for now, I've read and researched enough for now at least. There is a very good possibility I will follow up with a more practical article or an article concerning the cooperation of LVM and xen virtualization. Before that I will have to get more information myself :)

Further reading

Finally, if you really want to know the ins and outs on LVM, navigate here. It is the most excellent set of articles you could imagine. The information there goes well beyond the scope of this article. This was just me, writing what I learned from there and elsewhere in my own words. Its been just as much my lesson as yours :) Other sources include: LVM howto and good old wikipedia.