[libvirt-users] qcow2 performance

Trey Dockendorf treydock at gmail.com
Mon Feb 6 18:16:36 UTC 2012


On Mon, Feb 6, 2012 at 2:07 AM, Stefan G. Weichinger <lists at xunil.at> wrote:
> Am 06.02.2012 03:24, schrieb Trey Dockendorf:
>> I wouldn't consider this definitive, but I wrote an article doing
>> tests on qcow2 with the variables being preallocation and caching.
>> Essentially preallocation + no-cache is the fastest.  Article here,
>> http://itscblog.tamu.edu/improve-disk-io-performance-in-kvm/.  As of
>> virt-manager-0.9.0 the only way to generate the qcow2 with
>> preallocation is via command line.  Details of how are in the article.
>
> Additional question:
>
> Doesn't pre-allocation lose its meaning as soon as the image-file is
> fully allocated (I mean as soon as it is as big as its maximum size was
> defined at start)?
>
>
>

Sending response back to list incase someone finds it useful.

Preallocation works so that when you create a 100GB image it takes up
100GB from the start.  This helps performance because without
preallocation the disk would only take up space of whatever is stored
on it.  So each time you add files the filesystem as to grow the
image.  With qcow2 the preallocation is just metadata.  I've found
that ls -lh will show the size correctly but something like "df -h"
won't reflect the size of those images, nor will "du -h".

- Trey




More information about the libvirt-users mailing list