When I was first introduced to the Logical Volume Manager (LVM) in the 90s I was fascinated by its concept of mix-and-matching physical disk drives and transforming them into virtual devices (stripes, mirror, RAID) with a multitude of add-on services (snapshots, replication, VTL, and dedupe). It literally started the storage virtualization revolution.
The advent of compute and network virtualization, paired with fast internet access, have brought us today’s cloud services. But in all the recent noise about cloud, LVM seems to be missing in action. I started pondering over what happened to LVM. Does LVM even matter in today’s cloud environments?
Even though LVM has always been a great technology, it has never been easy to use. Today’s Linux LVM has no doubt come a long way in terms of functionalities and ease-of-use since its inception. Some Linux distributions even went so far as pre-configuring them as system root devices, making it effortless to use. However, it has not yet taken any advantage of the cloud, nor brought anything new to the cloud.
To find out more, I went on to search how people are using LVM in the cloud. Sadly, not much has turned up. With the few articles that turned up, most of them simply talked about using LVM in the traditional manner, nothing new or specific about the cloud. There’s just a great sense of loss in trying to find any synergy between the two. Worse, when I looked at the planet’s largest cloud provider AWS, its default Amazon Linux AMI doesn’t come pre-configured with LVM root device like some other Linux distributions have done for years.
Next I did a search on LVM’s benefits and tried to see if I can find out if they are still relevant. Most articles cited capabilities such as resizing volumes, thin volumes, and snapshots. It gradually became clear to me that not only LVM has not sharpened its edges by improving its usability or adding new features for quite some time, it’s also losing grounds to the cloud due to what cloud storage has to offer (AWS EBS come with snapshots, fault tolerance and high availability.
How about LVM’s ability to extend and reduce capacity? Let me be clear here I am not comparing LVM to the object storage that has no presumed capacity to begin with. I’m comparing it to the cloud block devices. I mean isn’t this what LVM was designed to do? Absolutely, but this took me back to the earlier question about what LVM brings to the cloud. For any tool to be useful at cloud scale it must be intelligent enough to operate unattended. LVM is certainly not one of them.
LVM is losing its relevance quickly in cloud. Cloud users need on-demand, elastic, automatically and transparently scalable cloud resources. LVM clearly was not designed for clouds and hasn’t kept up with changing customer needs in clouds.
One of the things the FittedCloud folks have come up with for the new cloud world is the ability to grow or shrink a virtual volume underneath a filesystem automatically according to its actual usage without bringing it down. Why? Because it addresses the issue that cloud vendors charge for the virtual volumes (e.g. AWS EBS) by its capacity/performance so if you over-provisioned them you’re paying for the capacity/performance you’re not using. And because it’s too laborious to use LVM to pull the same feat (search LVM thin volume and try it then multiply that by the cloud scale you will see what I mean.)
Editor's note: This post was originally published on the now retired FittedCloud blog (January 2018).
A hybrid IT approach offers the best of both on-premises and public cloud by keeping costs and risk low while increasing efficiency and speed. But monitoring and optimizing hybrid environments is complicated.