Qcow2 - Performance

lazy_refcounts

Qemu has supported a features called lazy_refcounts from version 1.2. This will noticeably improve the performance of qcow2 disk images when the guest is set to using the writethrough caching mode (which is the default). The tradeoff is that if the guest experiences a sudden power loss, an fsck-like pass will need to be made on the disk image before it can be used again. Luckily, the qemu-img check can now repair qcow2 and QED images with the new -r option.

Setting Cache Type

Below is an example section of an xml configuration of one of my guests where I have set the cache mode to none (on second line). I noticed that I didn't have a cache mode set, so it was probably defaulting to writethrough.

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2' cache='none'/>
  <source file='/path/to/disk.qcow2'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</disk>

Preallocation

There are four levels of preallocation of qcow2 disk images, listed below in order of least performance to greatest (for guest writes).

• preallocation=none
• preallocation=metadata
• preallocation=falloc
• preallocation=full

My rule of thumb is to use the metadata preallocation as it is quick to deploy small sparse images with a noticeable improvement over having no preallocation at all. If you really need more performance, then go with falloc or full.

Converting Existing Disk Images

If you wish to retrospectively "fix" existing disk images, then you can use the qemu-img convert command with the relevant options. E.g.

mv disk.qcow2 disk.qcow2.bak

qemu-img convert \
  -O qcow2 \
  -o lazy_refcounts=on,preallocation=metadata \
  disk.qcow2.bak \
  disk.qcow2

# check disk is fine before removing the original
rm disk.qcow2.bak

Slow Snapshotting

I had recently been suffering from incredibly slow snapshotting of one of my guests. It appears that I may have resolved it by using a script that shuts down the guest before taking the snapshot. In this case the guest had 4GB of RAM, and it appears that saving the memory state was taking up quite a bit of the time.

References

• Qemu Wiki - Changelog 1.2
• Description of Cache Modes
• JamesCoyle.net - qcow2 Disk Images and Performance
• KVM I/O slowness on RHEL 6
• JamesCoyle.net - qcow2 Physical Size With Different preallocation Settings
• RedHat Docs - Virtualization Tuning and Optimization Guide
• Launchpad - virsh snapshot-create too slow (kvm, qcow2, savevm)