11

I'm setting up a few KVM virtual guests and I'm debating which disk type to use. I haven't been able to find a good resource online that runs down the pros and cons of each.

Can you help me create a list of the different disk type and the advantages and disadvantages of each? Here are the disk types I know about:

  • Raw image
  • qcow2
  • Dedicated partition (eg, in LVM)

I'm curious about these criteria:

  • Ease of setup (how easy is it to create each type)
  • Performance
  • Ease of cloning
  • Ease of expanding (to make bigger, so the virtual guest has more disk space)
  • Features specific to that disk type
  • Ease of backup
  • Migration to other hosts

Can you help me evaluate my choices?

Barry Brown
  • 2,392
  • 4
  • 22
  • 23

3 Answers3

10

considering the consideration list you gave, definitely go with LVM. the only advantage to using qcow2 is it allowing for snapshots to be made. Those snapshots are far superior to LVM snapshots. RAW of course has no snapshot option at all, but a RAW image can be the base for a qcow2 snapshot.

  • Ease of setup (how easy is it to - create each type) : same for all, raw /qcow2 utilised by qemu-img, partitions/LVs by fdisk/lvm api
  • Performance : raw LVs or block devices are fastest, RAW files come next, qcow2 has the most overhead, but it's the most feature rich
  • Ease of cloning : qemu-img is used for that, and it can take into account already taken snapshots. with LVs ot other block devs, you'd probably need to use dd
  • Ease of expanding (to make - bigger, so the virtual guest has more disk space) : if this is important, LV is the best choice. Usually it is not, because you'd simply add another virtual disk or arbitrary size, and you also can overcommit storage by using sparse disks
  • Features specific to that disk type : qcow2 is the most feature rich format, as I've mentioned already. It can be combined with a raw image btw, use the raw as the base image, and qcow2 as snapshots
  • Ease of backup : copy a file, or dd/cpio - not really an issue
  • Migration to other hosts : for live migration you'd normally be using centralised storage, where there is no need for moving the image. Block migration is also possible. as for just moving the VM from host to host in offline mode - it's the same as backup/restore of the VM
dyasny
  • 18,482
  • 6
  • 48
  • 63
8

I would concentrate on raw image and LVM.

Raw image its easier to backup and copy, since it's just a file and you can do with it whatever you can do to a simple file. Also, avoiding specific formats you can easily use it, like mount it on a loop device to access the files in case of a crash or problem (or even on a backup server without virtualization). On the other hand, raw image files are affected by the kernel file cache, so you must be very careful when dealing with crashes and shutdowns, because the VM sync() doesn't really means that the host server sync()ed the file to a disk. I had many problems with that.

LVM bypass the cache problem, has better performance than files (AFAIK, it may have changed on the last months) and has the advantages of snapshots for backup. Changing the size of disks is also not complicated, but it's a little less trivial than raw files. Also with LVM you can setup DRBD for live migrations/failover.

In my opinion, go with LVM unless you have very specific needs for files.

coredump
  • 12,573
  • 2
  • 34
  • 53
4

Easier has its benefits, but I recently discovered the only disk format in KVM that permits snapshots that integrate memory and running state of the VM is qcow2 after playing around for a few minutes.

Community
  • 1
songei2f
  • 1,924
  • 1
  • 20
  • 30