[libvirt] Changing the default for qcow2 creation

Matthew Booth mbooth at redhat.com
Mon Oct 25 13:40:41 UTC 2010


I've recently been investigating a severe performance issue I noticed 
when writing to a qcow2-backed image. When virt-v2v is doing a format 
conversion from raw to qcow2, it does the following:

1. Create a new qcow2 image
2. Launch a libguestfs appliance (kvm) using the new image
3. Write the source raw data to the appliance's block device

I noticed that the same process writing to a raw image rather than a 
qcow2 image was adequately fast, and decided to do some testing. I've 
attached my simple test program.[1] It does the following:

1. Start an appliance with test.img as a disk.
2. Format test.img with ext2.
3. Create a file /test
4. Write 256M of data to /test in 2M chunks

Only step 4 is timed. I ran the program against test.img prepared in 4 
different ways:

1. A sparse raw file:                            15.3 seconds
     truncate --size 300M test.img
2. A preallocated raw file:                      14.8 seconds
     fallocate -l 300M test.img
3. A sparse qcow2 file:                         223.0 seconds
     qemu-img create -f qcow2 test.img 300M
4. A metadata preallocated qcow2 file:		 14.5 seconds
     qemu-img create -f qcow2 -o preallocated=metadata test.img 300M

With the exception of (3), I ran the test 3 times and took the middle 
time rounded to 1DP. I saw about 5-10% variation. I only ran the test 
against (3) once.

The precise ordering of 1, 2 and 4 is surprising, but given the 
variation probably not that interesting: they're all about the same. The 
interesting thing is that the overhead of qcow2 metadata creation during 
the test seems to account for a 15x performance penalty.

I had a cursory look at metadata preallocation, which I hadn't been 
aware of before today. Creating a qcow2 image of any size with no 
preallocation results in a 136k file. If you preallocate the metadata, a 
sparse file is created large enough to accomodate the entire image, with 
 >136k actually used. In the above 300M case this is 204k. On a slightly 
more practical 20G image, 3.3M is preallocated. It's also worth noting 
that the image takes considerably longer to create. On my laptop, 
creation without preallocation is 'instantaneous' at any size. With 
preallocation, a 20G image takes 6 seconds to create, and a 100G image 
takes 26 seconds.

libvirt's qemu driver doesn't currently preallocate qcow2 metadata when 
creating a new image. Given the tiny disk space overhead of the metadata 
(0.02%) and the small processing overhead of pre-creation relative to 
subsequent creation on-the-fly, I suggest that the libvirt qemu driver 
is updated to pre-allocate metadata by default.

Thoughts?

Matt

[1] Note that I'm running this against libguestfs from git, which uses 
virtio-serial rather than usermode networking for appliance<->host 
communication. This change alone improved the performance of this test 
by about 10x. If your numbers don't match mine, that's probably why. I 
don't know off the top of my head if this change has made it into F14 
yet. It's definitely not in F13.
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
-------------- next part --------------
A non-text attachment was scrubbed...
Name: write-test.pl
Type: application/x-perl
Size: 1080 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20101025/82ba937e/attachment-0001.pl>


More information about the libvir-list mailing list