On Tue, Dec 18, 2012 at 02:41:21PM +0100, Ján Tomko wrote: > Since 1.1 [1], QEMU supports qcow2 version 3 images. These are still > reffered to as qcow2 everywhere (qmp, qemu/qemu-img command line). > This format (besides some internal improvements) includes a bitfield of > compatible/incompatible/auto-clear features. [2] > > The only feature so far is delayed refcount updating (since 1.2 [3]), > which is compatible with 1.1 if the file has been closed properly, if > not it has the dirty flag set. > > For qcow2v3 images, -o compat=1.1 has to be passed to qemu-img. > (compat=0.10 means qcow2 which is the default at the moment) > For delayed refcount updates it's -o lazy_refcounts=on. > Using these options would require parsing 'qemu-img create -f qcow2 -o ? > /dev/null' output, or assuming they are supported. > > Do we need a new format type (qcow2v3) that translates to qcow2 for > qemu, or would XML like this be enough? > > <target> > <path>/var/lib/libvirt/images/image</path> > <format type='qcow2'/> > <features version='1.1'> > <lazy_refcounts compatible="no"/> > </features> > ... > </target> IMHO, libvirt simply needs to refer to the format as 'qcow3'. The fact that the QEMU has made their qcow2 driver handle qcow3 format images transparently is an impl detail. We can't assume that other impls (eg Xen) will do that, so we should treat 'qcow3' as an explicit format in the XML, and translate to what QEMU requires when invoking qemu or qemu-img. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list