On 05/17/2012 03:35 PM, Marc-André Lureau wrote:
Allow to specify preallocation mode for QCOW2 images. If not specified or not available, it's ignored.
This change only modify the schema, doc, parsing and tests. --- docs/formatstorage.html.in | 7 +++++++ docs/schemas/storagevol.rng | 18 ++++++++++++++++++ src/conf/storage_conf.c | 26 ++++++++++++++++++++++++++ src/conf/storage_conf.h | 1 + src/util/storage_file.c | 4 ++++ src/util/storage_file.h | 10 ++++++++++ tests/storagevolxml2xmlin/vol-qcow2.xml | 1 + tests/storagevolxml2xmlout/vol-qcow2.xml | 1 + 8 files changed, 68 insertions(+)
Meta-question - is pre-allocation something that is persistent with the existence of the storage volume, or is it something that is one-shot at the creation of the volume? If pre-allocation is a persistent property of the volume itself, then I would expect qemu-img to tell me whether an image is currently pre-allocated, as well as having knobs to tweak to force an image to become pre-allocated where it was not previously in that state. The converse direction, going from pre-allocated to sparse as a form of compression, might also be possible. If this is the case, then making pre-allocation part of the XML for describing a storage volume makes sense. On the other hand, if pre-allocation is only a knob to creation, but once the image is created it is no longer possible to tell whether it was created sparse or pre-allocated, nor is it possible to tweak the image to change between the two states at will, then it makes more sense to add a flag to the creation methods that specify whether to request pre-allocation, and to leave it out of the XML. I need to know the answer to that meta-question before I can review this part of the patch series. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org