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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list