Should LVM partitions be used in virtual machine images?

Question

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.

Answer 1

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 being done with it. It does mean one more step when 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 rigamarole and it isn't fast). So, if you are working on AWS I'd recommend using LVM.

Answer 2

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

Answer 3

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

Answer 4

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).

Answer 5

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.

Answer 6

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.