Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Should LVM be used for the partitions when creating VM images (e.g., KVM images)? It seems like it adds complexity if you want to, say, mount a qcow2 image in the host if the image has LVM partitions.

On the other hand, it doesn't seem like the advantages of LVM partitions are as significant on a VM image, since it's much easier to take a VM offline and resize partitions than it is for a physical system.

share|improve this question
Do you ask about using LVs as whole disks or as partitions that in turn make up a disk in a VM? – Nils Mar 5 '12 at 20:57
@Nils I'm talking about LVs as partitions that make up a disk. For example, having the "/" partition and the swap partition as logical volumes inside of a volume group. – Lorin Hochstein Mar 5 '12 at 21:08
Just to clarify, it seems like you were asking about using LVM on the guest side. It's much easier to manage if you use LVM on the host side, pass one disk or two, and use them without any partitioning on the guest. – Tobu Oct 3 '13 at 8:06
@Tobu Yes, I'm talking about on the guest side. – Lorin Hochstein Oct 3 '13 at 14:35
up vote 12 down vote accepted

I'd recommend not using LVM inside your VMs. It doesn't buy you much flexibility that you couldn't get at the hypervisor level.

Remember, the hypervisor is already effectively performing these tasks. If you want to be able to arbitrarily resize file systems (a fine idea), just create a separate virtual disk for each filesystem.

One thing you might think of as you go down this road. You don't even necessarily need to put partitions on your virtual disks this way. For example, you can create a virtual disk for /home; it is /dev/vdc inside your vm. When creating the filesystem, just do something like mke2fs -j /dev/vdc instead of specifying a partition.

This is a fine idea, but...most tools (and other admins who come after you) will expect to see partitions on every disk. I'd recommend just putting a single partition on the disk and be done with it. It does mean one more step when resizing the filesystem, though. And don't forget to properly align your partitions - starting the first partition at 1MB is a good rule of thumb.

EDIT - 2013-04-01 - not an april fool's joke :)

I've recently been doing some work with Amazon Elastic Compute Cloud. Virtual disks on AWS's block store are NOT trivially resizable (you can do it, but there's some rigmarole and it isn't fast). So, if you are working on AWS I'd recommend using LVM.

One final thought - Doing this all at the hypervisor level means that you probably have to reboot the VM to resize partitions. Using LVM would allow you to hot-add a virtual disk (presuming your hypervisor/OS combination allows this), and expand the filesystem without a reboot. This is definitely a plus.

share|improve this answer

Logical volumes are easier to create on the fly, resize, delete.
The "to LVM or not" question always has the same answer, it depends :)
It makes sense if you need the flexibility at the disk(s), partition(s) level.
It doesn't make much sense if you do not need the flexibility provided by LVM or do not want to take advantage of other LVM features

share|improve this answer

I actually like using LVs because they are not easily accessible from the virt-server. Thus these files can not easyly be destroyed/moved by chance.

Other important features of LVs:

  • You can make snapshots
  • You can analyze disk IO based on LV (iostat)
  • Easy to resize
  • By using snapshots you can make a consistent clone of running systems

To reduce complexity I use a LV as disk (not as partition). The drawback is that I can only easyly resize the last partition of the "disk" - but my standard-VM-disk-layout takes that into account (so the last partition contains the important application data).

share|improve this answer

In addition to flexibility, LVM based VM images have potentially less overhead, because they are not accessed through a filesystem. On the other hand, it takes away the means of easily moving images around, like you would do with a file. Not impossible, but a bit more complicated

share|improve this answer
That's an answer to a different question. The question here was about using LVM in the guests, not using LVM on the host (LVs to store the VM disks). – Stéphane Chazelas Oct 29 '15 at 17:13

I actually only use LVM's for the backing storage at the hypervisor level, image files are for the birds. I would also recommend using them at the guest level as well. It's true that you won't benefit from pooling disparate storage sources or find it easier to increase total disk space available (since you can get that just as easily by resizing what the hypervisor is presenting), but sometime you allocate too much to one filesystem. You might like an easy way to take 1 gig from /opt and give it to /var (for example). If you're doing regular partitions inside the VM itself then it makes the resizing aspect just that much harder.

share|improve this answer

In addition to the other good answers here, the only really good reason to use LVM inside a VM is you want a test environment to experiment with and get some practical hands-on experience with LVM.

You can go through various HOWTOs and tutorials, practice common (and not-so-common) LVM administration taks, set up various failure scenarios, and learn how to deal with them.

i.e. as a self-teaching aid.

share|improve this answer

Edit: The below is no longer true. The value of using thin provisioning provided by LVM for VM disk images is probably situational;

Are you running Development VM's on a laptop? then you're probably better off with QCow2.

Managing a farm of VM's that can possibly use vast amounts of storage across multiple disks? LVM is likely a good way to manage that storage.

one reason not to use lvm is you cannot overcommit storage using lvm. If you create an 10 VM's with 100GB of storage, you need 1000 GB of actual disk, even if 9 out of the ten VM's will only ever use 20 GB of their filesystems. Sparse Disk images or qcow2 format images can mean only the storage actually used by the guests need be allocated to them.

Whether this is actually useful to you depends on what you need out of your storage.

share|improve this answer
You actually can overcommit storage using lvm snapshots. It has overhead, though. – derobert Sep 13 '12 at 15:53
and actually, newer versions of LVM support a "thin pool", which is overcommit w/o any snapshot sillyness. – derobert Sep 13 '12 at 15:56
It's a valid point, albeit incorrect; the fact that the "standard"/on-the-fly way of using LVM partitions/disks results in the outlined scenario is certainly worth pointing out. Though, the answer could be changed to reflect that it would add even more complexity to the learning path. – ILMostro_7 2 days ago

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.