loading...

Ubuntu Server 18.04 – Utilizing LVM volumes

How to Install Windows Server 2019

The needs of your organization will change with time. While we as server administrators always do our best to configure resources with long-term growth in mind, budgets and changes in policy always seem to get in our way. LVM is something that I’m sure you’ll come to appreciate. In fact, technologies such as LVM are one of those things that make Linux the champion when it comes to scalability and cloud deployments. With LVM, you are able to resize your filesystems online, without needing to reboot your server.

Take the following scenario for example. Say you have an application running on a virtualized production server, a server that’s so important that downtime would cost your organization serious money. When the server was first set up, perhaps you gave
the application’s storage directory a 100 GB partition, thinking it would never need more than that. Now, with your business growing, it’s not only using a lot of space-you’re about to run out! What do you do? If the server was initially set up with LVM, you could add an additional storage volume, add it to your LVM pool, and grow your partition. All without rebooting your server! On the other hand, if you didn’t use LVM, you’re forced to find a maintenance window for your server and add more storage the old-fashioned way, which would include having it be inaccessible for a time.

With physical servers, you can install additional hard drives and keep them on standby without utilizing them to still gain the benefit of growing your filesystem online, even though your server isn’t virtual.

It’s for this reason that I must stress that you should always use LVM on storage volumes in virtual servers whenever possible. Let me repeat myself. You should always use LVM on storage volumes when you are setting up a virtual server! If you don’t, this will eventually catch up with you when your available space starts to run out and you find yourself working over the weekend to add new disks. This will involve manually syncing data from one disk to another and then migrating your users to the new disk. This is not a fun experience, believe me. You might not think you’ll be needing LVM right now, but you never know.

When setting up a new server via Ubuntu’s alternative installer, you’re given the option to use LVM during installation. But it’s much more important for your storage volumes to use LVM, and by those, I mean the volumes where your users and applications will store their data. LVM is a good choice for your Ubuntu Server’s root filesystem, but not required. In order to get started with LVM, there are a few concepts that we’ll need to understand, specifically volume groups, physical volumes, and logical volumes.

A volume group is a namespace given to all the physical and logical volumes on your system. Basically, a volume group is the highest name that encompasses your entire implementation of an LVM setup. Think of it as a kind of container that is able to contain disks. An example of this might be a volume group named vg-accounting. This volume group would be used for a location for the accounting department to store their files. It will encompass the physical volumes and logical volumes that will be in use by these users. It’s important to note that you aren’t limited to just a single volume group; you can have several, each with their own disks and volumes.

A physical volume is a physical or virtual hard disk that is a member of a volume group. For example, the hypothetical vg-accounting volume group may consist of three 100 GB hard disks, each called a physical volume. Keep in mind that these disks are still referred to as physical volumes, even when the disks are virtual. Basically, any block device that is owned by a volume group is a physical volume.

Finally, logical volumes are similar in concept to partitions. Logical volumes can take up a portion, or the whole, of a disk, but unlike standard partitions, they may also span multiple disks. For example, a logical volume can include three 100 GB disks and be configured such that you would receive a cumulative total of 300 GB. When mounted, users will be able to store files there just as they would a normal partition on a standard disk. When the volume gets full, you can add an additional disk and then grow the partition to increase its size. Your users would see it as a single storage area, even though it may consist of multiple disks.

The volume group can be named anything you’d like, but I always give mine names that begin with vg- and end with a name detailing its purpose. As I mentioned, you can have multiple volume groups. Therefore, you can have vg-accounting, vg-sales, and vg-techsupport (and so on) all on the same server. Then, you assign physical volumes to each. For example, you can add a 500 GB disk to your server and assign it to vg-sales. From that point on, the vg-sales volume group owns that disk. You’re able to split up your physical volumes any way that makes sense to you. Then, you can create logical volumes utilizing these physical volumes, which is what your users will use.

I think it’s always best to work through an example when it comes to learning a new concept, so I’ll walk you through such a scenario. In my case, I just created a local Ubuntu Server VM on my machine via VirtualBox and then I added four additional 20 GB disks after I installed the distribution. Virtualization is a good way to play around with learning LVM if you don’t have a server available with multiple free physical disks.

To get started with LVM, you’ll first need to install the required packages, which may or may not be present on your server. To find out if the required lvm2 package is installed on your server, execute the following command:

dpkg -s lvm2 | grep status

If it’s not present (the output of the previous command doesn’t come back as install ok installed, the following command will install the lvm2 package and its dependencies:

sudo apt install lvm2

Next, we’ll need to take an inventory of the disks we have available to work with. You can list them with the fdisk -l command as we’ve done several times now. In my case, I have /dev/sdb, /dev/sdc, /dev/sdd, and /dev/sde to work with. The names of your disks will be different depending on your hardware or virtualization platform, so make sure to adjust all of the following commands accordingly. To begin, we’ll need to configure each disk to be used with LVM, by setting up each one as a physical volume. The pvcreate command allows us to create physical volumes, so we’ll need to run the pvcreate command against all of the drives we wish to use for this purpose. Since I have four, I’ll use the following to set them up:

sudo pvcreate /dev/sdb
sudo pvcreate /dev/sdc
sudo pvcreate /dev/sdd
sudo pvcreate /dev/sde

And so on, for however many disks you plan on using.

To confirm that you have followed the steps correctly, you can use the pvdisplay command as root to display the physical volumes you have available on your server:

Output of the pvdisplay command on a sample server

Although we have some physical volumes to work with, none of them are assigned to a volume group. In fact, we haven’t even created a volume group yet. We can now create our volume group with the vgcreate command, where we’ll give our volume group a name and assign our first disk to it:

sudo vgcreate vg-test /dev/sdb1

Here, I’m creating a volume group named vg-test and I’m assigning it one of the physical volumes I prepared earlier (/dev/sdb). Now that our volume group is created, we can use the vgdisplay command to view details about it, including the number of assigned disks (which should now be 1):

Output of the vgdisplay command on a sample server

At this point, if you created four virtual disks as I have, you have three more disks left that are not part of the volume group. Don’t worry, we’ll come back to them later. Let’s forget about them for now as there are other concepts to work on at the moment.

All we need to do at this point is create a logical volume and format it. Our volume group can contain all, or a portion, of the disk we’ve assigned to it. With the following command, I’ll create a logical volume of 10 GB, out of the 20 GB disk I added to the volume group:

sudo lvcreate -n myvol1 -L 10g vg-test

The command may look complicated, but it’s not. In this example, I’m giving my logical volume a name of myvol1 with the -n option. Since I only want to give it 10 GB of space, I use the -L option and then 10g to represent 10 GB. Finally, I give the name of the volume group that this logical volume will be assigned to. You can run lvdisplay to see information regarding this volume:

sudo lvdisplay
Output of the lvdisplay command on a sample server

Next, we need to format our logical volume so that it can be used. However, as always, we need to know the name of the device so we know what it is we’re formatting. With LVM this is easy. The lvdisplay command gave us this already, you can see it in the output (it’s the third line down in the previous screenshot under LV Path). Let’s format it:

sudo mkfs.ext4 /dev/vg-test/myvol1

And now this device can be mounted as any other hard disk. I’ll mount mine at /mnt/lvm/myvol1, but you can use any directory name you wish:

sudo mount /dev/vg-test/myvol1 /mnt/lvm/myvol1

To check our work, execute df -h to ensure that our volume is mounted and shows the correct size. We now have an LVM configuration containing just a single disk, so this isn’t very useful. The 10 GB I’ve given it will not likely last very long, but there is some remaining space we can use that we haven’t utilized yet. With the following command, I can resize my logical volume to take up the remainder of the physical volume:

sudo lvextend -n /dev/vg-test/myvol1 -l +100%FREE

If done correctly, you should see output similar to the following:

Logical volume vg-test/myvol1 successfully resized.

Now my logical volume is using the entire physical volume I assigned to it. Be careful, though, because if I had multiple physical volumes assigned, that command would’ve claimed all the space on those as well, giving the logical volume a size that is the total of all the space it has available, across all its disks. You may not always want to do this, but since I only had one physical volume anyway, I don’t mind. If you check your mounted disks with the df -h command, you should see this volume is mounted:

df -h

Unfortunately, it’s not showing the extra space we’ve given the volume. The output of df is still showing the size the volume was before. That’s because although we have a larger logical volume, and it has all the space assigned to it, we didn’t actually resize the ext4 filesystem that resides on this logical volume. To do that, we will use the resize2fs command:

sudo resize2fs /dev/mapper/vg--test-myvol1
The double-hyphen in the previous command is intentional, so make sure you’re typing the command correctly.

If run correctly, you should see output similar to the following:

The filesystem on /dev/mapper/vg--test-myvol1 is now 5241856 (4k) blocks long.

Now you should see the added space as usable when you execute df -h. The coolest part is that we resized an entire filesystem without having to restart the server. In this scenario, if our users have got to the point where they have utilized the majority of their free space, we will be able to give them more space without disrupting their work.

However, you may have additional physical volumes that have yet to be assigned to a volume group. In my example, I created four and have only used one in the LVM configuration so far. We can add additional physical volumes to our volume group with the vgextend command. In my case, I’ll run this against the three remaining drives. If you have additional physical volumes, feel free to add yours with the same commands I use, but substitute my device names with yours:

sudo vgextend vg-test /dev/sdc
sudo vgextend vg-test /dev/sdd
sudo vgextend vg-test /dev/sde

You should see a confirmation similar to the following:

Volume group "vg-test" successfully extended

When you run pvdisplay now, you should see the additional physical volumes attached that weren’t shown there before. Now that we have extra disks in our LVM configuration, we have some additional options. We could give all the extra space to our logical volume right away and extend it as we did before. However, I think it’s better to withhold some of the space from our users. That way, if our users do use up all our available space again, we have an emergency reserve of space we could use in a pinch if we needed to while we figure out the long-term solution. In addition, LVM snapshots (which we will discuss soon) require you to have unallocated space in your LVM.

The following example command will add an additional 10 GB to the logical volume:

sudo lvextend -L+10g /dev/vg-test/myvol1

And finally, make the free space available to the filesystem:

sudo resize2fs /dev/vg-test/myvol1
With very large volumes, the resize may take some time to complete. If you don’t see the additional space right away, you may see it gradually increase every few seconds until all the new space is completely allocated.

As you can see, LVM is very useful for managing storage on your server. It gives you the ability to scale your server’s storage as the needs of your organizations and users evolve. However, what if I told you that being able to resize your storage on command isn’t the only benefit of LVM? In fact, LVM also allows you to perform snapshots as well.

LVM snapshots allow you to capture a logical volume at a certain point in time and preserve it. After you create a snapshot, you can mount it as you would any other logical volume and even revert your volume group to the snapshot in case something fails. In practice, this is useful if you want to test some potentially risky changes to files stored within a volume, but want the insurance that if something goes wrong, you can always undo your changes and go back to how things were. LVM snapshots allow you to do just that. LVM snapshots require you to have some unallocated space in your volume group.

However, LVM snapshots are definitely not a viable form of backup. For the most part, these snapshots are best when used as a temporary holding area when running tests or testing out experimental software. If you used Ubuntu’s alternative installer, you were offered the option to create an LVM configuration during installation of Ubuntu Server, so therefore you can use snapshots to test how security updates will affect your server if you used LVM for your root filesystem. If the new updates start to cause problems, you can always revert back. When you’re done testing, you should merge or remove your snapshot.

So, why did I refer to LVM snapshots as a temporary solution and not a backup? First, backups aren’t secure if they are stored on the same server that’s being backed up. It’s always important to save backups off the server at least, preferably off-site. But what’s worse is that if your snapshot starts to use up all available space in your volume group, it can get corrupted and stop working. Therefore, this is a feature you would use with caution, just as a means of testing something, and then revert back or delete the snapshot when you’re done experimenting.

When you create a snapshot with LVM, what happens is a new logical volume is created that is a clone of the original. Initially, no space is consumed by this snapshot. But as you run your server and manipulate files in your volume group, the original blocks are copied to the snapshot as you change them, to preserve the original logical volume. If you don’t keep an eye on usage, you may lose data if you aren’t careful and the logical volume will fill up.

To show this in an example, the following command will create a snapshot (called mysnapshot) of the myvol1 logical volume:

sudo lvcreate -s -n mysnapshot -L 4g vg-test/myvol1

You should see the following output:

Logical volume "mysnapshot" created.

With that example, we’re using the lvcreate command, with the -s option (snapshot) and the -n option (which allows us to name the snapshot), where we declare a name of mysnapshot. We’re also using the -L option to designate a maximum size for the snapshot, which I set to 4 GB in this case. Finally, I give it the volume group and logical volume name, separated by a forward slash (/). From here, we can use the lvs command to monitor its size.

Since we’re creating a new logical volume when we create a snapshot, we can mount it as we would a normal logical volume. This is extremely useful if we want to pull a single file without having to restore the entire thing. If we would like to remove the snapshot, we can do so with the lvconvert command:

sudo lvconvert --merge vg-test/mysnapshot

The output will look similar to the following:

Merging of volume mysnapshot started.
myvol1: Merged: 100.0%

It’s important to note, however, that unlike being able to resize a logical volume online, we cannot merge a snapshot while it is in use. If you do, the changes will take effect the next time it is mounted. Therefore, you can either unmount the logical volume before merging, or ummount and remount after merging. Afterwards, you’ll see that the snapshot is removed the next time you run the lvs command.

Finally, you may be curious about how to remove a logical volume or volume group. For these purposes, you would use the lvremove or vgremove commands. It goes without saying that these commands are destructive, but they are useful in situations where you want to delete a logical volume or volume group. To remove a logical volume, the following syntax will do the trick:

sudo lvremove vg-test/myvol1

Basically, all you’re doing is giving the lvremove command the name of your volume group, a forward slash, and then the name of the logical volume within that group that you would like to remove. To remove the entire volume group, the following command and syntax should be fairly self-explanatory:

sudo vgremove vg-test

Hopefully, you’re convinced by now how awesome LVM is. It allows you flexibility over your server’s storage that other platforms can only dream of. The flexibility of LVM is one of the many reasons why Linux excels in the cloud market. These concepts can be difficult to grasp at first if you haven’t worked with LVM before. But thanks to virtualization, playing around with LVM is easy. I recommend you practice creating, modifying, and destroying volume groups and logical volumes until you get the hang of it. If the concepts aren’t clear now, they will be with practice.

Comments are closed.

loading...