Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
Though I have been using and studying GNU/Linux for quite some time now, LVM is a new beast in my menagerie. Perhaps other aspects of system administration seemed more interesting, or maybe I didn’t feel the need for LVM. But now that I know more about it, it is fast becoming an essential part of my toolkit.

If we take a look at back issues of our favorite magazine (Full Circle Mag, what other?), we actually find that LVM is mentioned very few times. It did appear in the 2011 “Special Edition 01: the Perfect Server”, and it was also mentioned briefly in issues 31 and 67. But there have been no in-depth articles on the matter.

For today, after giving a simple example to put all the pieces in place, we will look at three different scenarios, covering some real-world, hands-on applications for LVM. In the first, we will use LVM to give us some flexibility when installing a new system. This will be a system for which we do not really know from day one exactly what disk space requirements will arise for our system and user document partitions. Should we retain a Windows partition, or will we want to remove it later on and combine this space with our Ubuntu partitions? In the second scenario, we will see how the LVM snapshot capability may be a life-saver if we should want to upgrade an existing system, without risking losing it all. Finally, in the third case we will be creating a bootable USB drive with several Ubuntu (or other) distributions all at once, so we can boot a computer from any of them.

What LVM is

Normal disk management under GNU/Linux - and also under Ubuntu - consists of working with disk partitions on the one hand, and file-systems on the other. Disk partitions are the low-level divisions of our disks. If you start out with a disk detected by the system as /dev/sda, it may contain partitions /dev/sda1, /dev/sda2, etc. Each of these partitions can then be formatted using a file-system: extended for GNU/Linux, NTFS or VFAT for Windows, HFS for Mac-OS-X, etc. The limitation with this scheme is that each partition can support one single file-system.

The main idea behind the Logical Volume Manager (LVM) is to insert a third layer between the physical partitions on one hand, and file-systems on the other. This is an abstraction layer that makes file-systems more independent from the physical disks beneath. Physical disks are grouped together into this abstraction layer on one side, and then file-systems are created on the other that are completely independent from the disks.

A simple example

To use LVM, in the first place one should make sure we have the appropriate programs installed. They come as standard on most modern Ubuntu versions (13.04, 13.10, …) and derivatives (e.g. Linux Mint 15). They can also be installed on earlier versions - look for package lvm2 in your favorite software manager.

Once the software is installed, we need to go through three steps:

1. We convert our physical disk partitions to LVM Physical Volumes (PV). Each partition converted will no longer be able to support a file-system directly, so we must be sure they do not contain any data we wish to keep.

2. We group our Physical Volumes together into a Volume Group (VG). There is no actual need to have more than one PV in a particular VG, but if needed we may do so. PVs are then combined within the VG, and their sizes add up. The group then be used as a single pool of disk space we can split into chunks and use as we wish.

3. We create one or more Logical Volumes out of our Volume Group. 

To take a practice example, we could start out with a computer with two drives, /dev/sdc and /dev/sdd, both being 2 TB volumes. sdc holds a single partition occupying the whole disk and noted sdc1, while sdd is divided into sdd1 and sdd2, both with 1 TB. We want to use sdc1 and sdd2 with LVM, conserving sdd1 without making any changes to it. 

Step 1 would be:

sudo bash

(we need to be root to alter LVM volumes)

pvcreate /dev/sdc1

pvcreate /dev/sdd2

Once we have the two PVs created, we can create our volume group to host them. The VG may be called just about anything (but no spaces or “weird” characters in the name), so in this case we will simply call it “group”. So we will create it first with one volume, then add the second:

vgcreate group /dev/sdc1

vgextend group /dev/sdd2

We now obtain a single volume group, with total capacity 3 TB. We can now proceed to step 3, and “carve” out one or more logical volumes as necessary - and yes, the technical term used is indeed “to carve”. For example, if we wished to create a 1.5 TB volume we will be using as a backup, we could do it this way:

lvcreate group -L 1500M -n backup

Giving the LV a significant name with the -n option will make it easier for us to recognize and use. For example:

mkfs.ext4 /dev/group/backup

mount /dev/group/backup /mnt


Note that LV divisions borders do not necessarily coincide with disk partitions; in this example our backup LV may in actual fact be completely contained within /dev/sdc1, or it could just as well be divided up into chunks physically located on both /dev/sdc1 and /dev/sdd2. We do not have to manage it. On the other hand, we do know we still have some 1.5 TB of free space we can further carve up – into one or several more LVs. So this simple example already shows us some of LVM’s potential flexibility.

Though I personally prefer to use the console, not everybody feels that way. So a graphical front-end for LVM has been developed, called system-config-lvm. If you feel so inclined, by all means install it on top of lvm and give it a test. It also outputs some pretty graphics such as those above. However, it does have some issues with recent versions of Linux Mint and Cinnamon (but not with Unity). 

Scenario 1: juggling disks when you do not know what the final system will look like

Most of us have installed Ubuntu or one of its derivatives on a disk that already contained a Windows partition. At least at the very beginning, we often wanted to retain at least part of the Windows installation, just in case we wanted to go back - for whatever reason. At the end of the day, however, this “going back” somehow rarely happens. What does happen is that we run out of space on the Linux side, and end up thinking of adding the Windows partition or partitions to Ubuntu. LVM makes this easier.

Let us set out with a typical laptop hard drive, that often comes from the factory preset with three partitions:
• /dev/sda1 as C:, the main Windows system disk;
• /dev/sda2 as D:, where we place our files, often set up as the My Documents folder;
• /dev/sda3, an invisible partition under Windows that holds a system image that can be used to reinstall Windows to its factory settings.

A simple installation choice is to replace the NTFS D: partition with our Ubuntu system. If we simply discard the existing D: and give the installer free reign we will probably end up with something a tad complicated. It loves to create two separate partitions, one for the system itself, and another as swap memory. So we could end up with something like this:
• /dev/sda1 as the existing C:
• /dev/sda2 as an ext4 partition
• /dev/sda4, a primary partition containing
• /dev/sda5, a secondary partition used as swap
• /dev/sda3, the existing invisible image partition

This is already a bit involved, and will become even more so when, later on, we decide to get rid of Windows once and for all, and reuse /dev/sda1 and /dev/sda3 for Ubuntu as well.

So, in comes LVM to help us simplify things. When installing Ubuntu for the first time, instead of going directly to the installer, we will fire up a terminal, become root and:

sudo bash

(no password is necessary with the LiveCD)

pvcreate /dev/sda2

vgcreate group /dev/sda2

vgcreate group -n system -L <system size>

vgcreate group -n swap -L <swap size>

We now have:
• /dev/sda1 as the existing C:
• /dev/sda2 as a PV, used by VG “group” and containing
• /dev/group/system, a partition we will use as the system root
• /dev/group/swap, a partition used as swap
• /dev/sda3, the existing invisible image partition

We can now proceed to the Ubuntu installer, and when presented with the screen to choose disk management, go to “manual partitioning”. From there, we get /dev/group/system formatted as an ext4 file-system and mounted on /, while /dev/group/swap gets formatted and used as swap. The rest of the system installation process should go on as usual.

A word of warning: earlier versions of Ubuntu were not LVM-aware. What is described here should work out-of-the-box for Raring (13.04) and Saucy (13.10), as well as Linux Mint 15. Earlier versions need some heavy-duty console work to mount the target partition, bind-mount accessory directories such as /tmp and /dev; go to it in a chroot jail and install the lvm2 package. This is certainly doable, but perhaps not for the faint of heart.

Now, what happens when we wish to add the Windows partitions to our Ubuntu system? Let us say, for example, that we simply wish to reform /dev/sda1 (C:), retaining the image partition for the time being. Inside a terminal, we create a new PV from /dev/sda1, and add it to VG “ubuntu”:

sudo bash

pvcreate /dev/sda1

vgextend group /dev/sda1

If we now use the vgdisplay command, it can be seen that the space available on VG “ubuntu” is larger than before, comprising both /dev/sda2 and /dev/sda1. We can then make our LV “system” and root file-system larger. This cannot be done while it is mounted, so we will need to boot from the Ubuntu LiveCD once more. Supposing our /dev/sda1 partition was 40 GBytes in size, and /dev/sda2 was 60 GBytes, we could:

sudo bash

lvextend /dev/ubuntu/system +40G

(adds the newly available 40 GB to LV “system”)

resize2fs /dev/ubuntu/system 100G

(makes the “system” ext4 filesystem a total of 100 GB large)

We should then be able to reboot as usual from the hard disk, and test drive our new, enlarged, system. Our system now looks like this:
• /dev/sda1 and /dev/sda2 as PVs, used by VG “group” and containing
• /dev/group/system, a partition we will use as the system root
• /dev/group/swap, a partition used as swap
• /dev/sda3, the existing invisible image partition

If we do not need the image partition any more, we could also go one step further, and add it as well to VG “group”.

The usual warnings apply: we are making extensive changes to the operating system, so things could eventually go very wrong. Naturally, you should do this for the first time only on a system which you are prepared to reinstall from scratch if things go bad. And, of course, make a backup of your data before starting!

Scenario 2: a safety net when upgrading an existing system

One of the nice things about Ubuntu and GNU/Linux systems in general is that new, upgraded versions come up very often, in our case every six months. So there is a natural tendency to upgrade systems that may or may not really need it - just to stay on top of things. But strange things do sometimes happen when upgrading, even with Linux. For example, in theory it should be possible to upgrade an existing Ubuntu-based system to a newer version by simply changing the repositories in /etc/apt/sources.list and then executing

sudo bash

aptitude update ; aptitude safe-upgrade -y ; shutdown -r now

In actual fact, this is not a good idea for many distributions. Some old cruft always gets carried over to the new version. More importantly, new versions may need newer versions of their configuration files, that might even not be in the same directories any more. This is particularly true of Linux Mint: except for their Debian-based distributions (LMDE), upgrading in place has specifically been discouraged - see Clément Lefebvre’s “How to upgrade to a newer release” (http://community.linuxmint.com/tutorial/view/2).

Anyhow, if downloading, installing and re-configuring a new system is just too much hassle and you do want to go down the path of in-place upgrading, it is always nice to have a Plan B ready: a way to get your system back up and working as it was before trying to upgrade. Once more, LVM comes to the rescue with its snapshot capability.

The way this works is, if we have enough free space in our VG, we create a second LV that is essentially a copy of the first, though in essence “frozen in time”. We can then do whatever we want to the first LV, and can always copy our files back from the snapshot if needed.

First, we create the snapshot of LV “system”. In my own case, I tend to use very small 10 GByte system partitions, so I will create a snapshot reserving double this space - just in case it fills up for whatever reason. We will call the snapshot “system-snap”:

sudo bash

lvcreate -s -n system-snap -L 20G /dev/group/system

That’s it, all done. Now we can proceed to upgrade our system to whatever newer version is available (Ubuntu 13.10, perhaps?), or perform any other kind of black magic that could eventually bork things in a big way. 

Let us suppose that it has indeed done that, and that our original system (in LV “system”) is in a very bad shape. We need to reboot from the trusty Ubuntu LiveCD, and in a terminal make a copy of the snapshot we will work from:

sudo bash

lvrename /dev/group/system system-old

lvcreate group -n system -L 10G 

(put in here whatever size you used for the system partition)

dd if=/dev/group/system-snap of=/dev/group/system bs=1M

At this point, LVs should be this way:

lvscan
  
ACTIVE Original '/dev/group/system-old' [10,00 GiB] inherit
  
ACTIVE Snapshot '/dev/group/system-snap' [20,00 GiB] inherit
  
ACTIVE  '/dev/group/system' [10,00 GiB] inherit

The “system-old” LV is the old, wrecked system. “system-snap” is the snapshot containing a copy of the system as it was before making the fatal changes, and “system” is the current, recreated, system.

We can clean up a bit by removing both the old system and the snapshot, regaining the space they occupied:

lvremove /dev/group/system-snap

lvremove /dev/group/system-old

Depending on what happened while upgrading/breaking your system, your GRUB installation may also be off-course. It is perhaps a good idea to recreate it while you are still booted into the LiveCD. Mount your new /dev/group/system, for example on /media/ubuntu/system, and reinstall GRUB on /dev/sda with:

grub-install --boot-directory /media/ubuntu/system/boot /dev/sda

Scenario 3: making your “Swiss army knife” USB boot disk

In this day and age of external USB hard drives, we have at our disposal a simple means of booting ailing computers, and fixing whatever is wrong or even cloning a system image. The standard Ubuntu LiveCD image can help us, naturally, but another way of going about it is to simply install Ubuntu on an external drive. That way, we can add our very own collection of tools and keep it set up just the way we want it.

However, some tasks need simple tools such as booting a very old computer off a lightweight Xubuntu, while others may need a more complete solution, such as cloning a school lab’s worth of computers all to the same spec with Ubuntu Studio. Since modern hard drives have plenty of space, why not put several different distributions on the same external drive?

However, we may encounter several practical problems. If we want to use the disk to boot older computers, we will need to use the classical Master Boot Record (MBR) partitioning system. This means we are limited to four principal partitions - slightly more if we use secondary partitions, but still very limited in number. So, even if the hard disk itself has more than enough capacity for several dozen Ubuntu installations - perhaps of varying ages and flavors - the partition map will not take them.

Even worse is that unless we plan very carefully beforehand how much space to assign to each installation, we may end up with some partitions running out of space, while there is plenty left over on the disk. A case in point would be if we have a backup partition on disk, as well as the system installations.

At this point, it should be clear that we would be better off using LVM on the external disk. 

Setting it up is simplicity itself. Once we have booted from the LiveCD for the first Ubuntu system we wish to install, we use the terminal or the gparted utility to create a first ext4 partition occupying the entire external disk: /dev/sda1 or similar. Once that is done, we can proceed to the terminal, create a PV from the partition, and a VG from that. Then we can carve out a first LV from the VG, format it and install Ubuntu on it.

For successive installations of other versions of *buntu, we proceed in the same way: boot from the appropriate LiveCD, use the terminal to create a new LV (use significant volume labels!), format the new LV with an ext4 file-system, an install in the traditional way. Each time, however, the GRUB installation will probably get overwritten by the installer so, whatever you do, make sure beforehand the version of Ubuntu you are installing does actually support lvm out of the box! Just run any of the commands - lvdisplay will suffice - from the terminal.

A helpful tip: it is best to practice installing Ubuntu on an external disk on a computer with its internal hard drive disconnected. Doing things this way can help avoid wee mistakes, such as overwriting the main hard drive’s system inadvertently...

Conclusions

Though LVM may seem to be a bit of overkill for a simple Ubuntu installation, as we have seen in these three scenarios - installing GNU/Linux on a (former) Windows machine, using a snapshot to keep our backs covered when upgrading in place, and making an external USB boot diskb - it does give us a lot of flexibility. Without LVM, one partition must correspond to precisely one file-system. With LVM, we can play separately on two different levels: with partitions on the one hand, and with Logical Volumes on the other. While I hope these three scenarios may help the reader in real-life situations, this is by no means the end of LVM applications. Further possibilities include using it to encrypt a complete partition - as set out in Xavier Berger’s “Create a thief-proof PC”, in Full Circle issue 67 (http://fullcirclemagazine.org/issue-67/). If we want to set up a data repository or NAS box on our network, LVM mirroring gets us data replication (two copies of each item) without having to fiddle around with RAID volumes.

In any case, I would like to encourage everybody to play around with LVM, at least to explore its various possibilities. But please stay safe: do it on a computer you do not need for work, that you are happy to format if need be, and obviously with all data on it correctly backed up. Even small units such as USB flash pen-drives are enough to try out LVM, though the system may or may not regain access to the LVs if you pop them out and back in again (it usually does). Perhaps the best way to test it out would be with virtual machines under Virtualbox. If your main computer has enough RAM (say 2 GB), enough CPU horsepower (any dual-core should suffice) and some space disk space left, this would definitely be the way to go.