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(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org