LVM, Demystified

Two Peas in a Pod

If you look at the first "stage" in my drawing (Figure 1), you'll notice that I didn't call the 10GB chunks "drives"; I called them physical volumes. That's because although it's certainly possible to use a physical drive as a physical volume in LVM, it's not a requirement. In fact, it's not even the most common scenario. In most production environments, LVM is used in combination with RAID. Whether that's hardware-based RAID or software-based RAID, having your underlying physical volumes exist as RAID devices is ideal.

As someone who has had problems with hardware-based RAID arrays, I tend to lean toward software-based RAID in my systems. That's certainly a matter of personal preference, but it's good to know that since software-based RAID and LVM both operate at the kernel level, both are extremely efficient. Software-based RAID admittedly uses some CPU, especially when rebuilding arrays, but LVM uses very little. If I/O performance is of utmost importance for your purposes, it's worth doing some research and possibly testing before committing to any solution.

Getting Started

Although it's certainly possible to transition to an LVM system after Linux is already installed, it's far more preferable to do so during the initial setup. Most distributions allow for LVM setup to take place during the installation process, and in the case of CentOS and RHEL, LVM is used by default. Even if you're installing only onto a single, non-RAID hard drive, setting up LVM allows you flexibility and expansion opportunity later. Heck, it's possible to add RAID to a server later on, then simply migrate the data from your original physical volume to the RAID physical volume. That's far easier than using dd, especially when you'd like to keep your server running!

Because this is an introduction, let me start with a simplistic setup. Let's say you have two hard drives, /dev/sdb and /dev/sdc. With LVM, any block device can be used as a physical volume (PV), which means you can use either partitions or entire drives. If you need to have a "traditional" partition (in some cases, the /boot partition might need to be on a regular, non-LVM device), be sure to partition the drive before adding the physical volumes to your volume group. In this example, let's use the raw disks themselves.

Step 1: Create Physical Volumes

Once you have the block devices you want to add to your volume group (again, keep referring to my drawing if the terms get confusing), you need to establish them as LVM physical volumes. To do that, use the pvcreate command:


pvcreate /dev/sdb
pvcreate /dev/sdc

These commands configure the drives as potential candidates to be added to a volume group. If you want to make sure it worked correctly, you can type pvdisplay or pvscan to show the status of any existing LVM Physical Volumes:


$ sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/sdb
  VG Name               
  PV Size               10.4 GiB / not usable 3.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              4994
  Free PE               4994
  Allocated PE          0
  PV UUID               SRKAXh-EpYr-r2td-g0gA-31RA-fnfz-3qqGrO
   
  --- Physical volume ---
  PV Name               /dev/sdc
  VG Name               
  PV Size               10.4 GiB / not usable 3.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              4994
  Free PE               4994
  Allocated PE          0
  PV UUID               t2cKru-IwMy-I8re-ADp2-vzFF-Tvh5-O4zMhI

And, the simpler pvscan:


$ sudo pvscan
  PV /dev/sdb         lvm2 [10.4 GiB]
  PV /dev/sdc         lvm2 [10.4 GiB]
  Total: 2 [20.8 GiB] / in use: 0 [0 ] / in no VG: 2 [20.8 GiB]

Once you create the volume group and logical volumes, go ahead and run these commands again to see how the information changes. The differences should be obvious and should make sense.

______________________

Shawn Powers is an Associate Editor for Linux Journal. You might find him chatting on the IRC channel, or Twitter

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix