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,
but in snapshot XML we treat the driver type as the format:
<disk name='/path/to/old'>
<driver type='qcow3'/>
<source file='/path/to/new'/>
<features>
<lazy_refcounts/>
</features>
</disk>
So I think we should allow the qcow3 driver type as well and translate
it to qcow2 for QEMU.
Jan
[1] v2 here:
https://www.redhat.com/archives/libvir-list/2013-February/msg00212.html
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list