[libvirt] Changing the default for qcow2 creation

[Richard W.M. Jones]

On Mon, Oct 25, 2010 at 02:40:41PM +0100, Matthew Booth wrote:
> 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?

Your test might run faster if you did:

  $g->copy_size ("/dev/zero", "/test", <size of file>);

However I think making the change is a no-brainer.  We should add this
flag by default.

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

F13 and F14 both use virtio-serial now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora