Am 04.03.2013 um 14:09 hat Daniel P. Berrange geschrieben:
On Mon, Mar 04, 2013 at 01:58:12PM +0100, Ján Tomko wrote:
Before posting another version of my patches [1], attempting to add support for the new qcow format to libvirt, I would like to know if this sounds reasonable:
A new format named 'qcow3' would be added, along with a <features> sub-element for target.
<volume> <name>qcow3test</name> <source> </source> <capacity unit='GiB'>8</capacity> <target> <path>/var/lib/libvirt/images/qcow3test</path> <format type='qcow3'/> <features> <lazy_refcounts/> </features> </target> </volume>
I think that libvirt shouldn't care if the features are compatible or incompatible, as we don't know what features are supported by the hypervisor. Would the features be any good as tri-state (on, off, default?).
While the qcow3 format is handled by the qcow2 driver in QEMU, <driver name='qemu' type='qcow2'/> should be enough for domains,
We should use qcow3 everywhere IMHO, regardless of whether qcow2 technically works in this context.
I think it makes much more sense to deal with it the way qemu does instead of inventing new names. This has much more of an (incompatible) feature flag than of a different image format. So to fit it in your proposed syntax: <target> <path>/var/lib/libvirt/images/qcow3test</path> <format type='qcow2'/> <features> <compat version="1.1" /> <lazy_refcounts/> </features> </target> Or if you really think that you should refer to the inner workings of qcow2, you can make it <version>3</version>. But I guess you call all VMDKs just "vmdk", despite the fact that they are really just a collection of different subformats. Right? Kevin