On Tue, May 1, 2018 at 10:45 AM, Daniel P. Berrangé <berrange@redhat.com> wrote:

On Tue, Jan 30, 2018 at 01:17:21PM +0100, Gionatan Danti wrote:
> Hi all,
> on a fully patched CentOS 7.4 x86-64, I see the following behavior:
>
> - when creating a new volumes using vol-create-as, the resulting file is a
> qcow2 version 2 (compat=0.10) file. Example:
>
> [root@gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2
> 8589934592 --format=qcow2 --backing-vol /mnt/vmimages/centos6.img
> Vol zzz.qcow2 created

Yes, for sake of backcompat we default to v2 unless something
requires v3. You can't use vol-create-as to create a v3 image,
you need to use the XML input.

BTW: in virt-manager of CentOS 7.4 by default qcow2 disks (see below for zzz3.qcow2) are created with compatibility 1.1 (probably indirectly because of its lazy refcounts feature enabled, as Daniel wrote):

[root@c7client images]# qemu-img info zzz3.qcow2
image: zzz3.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 516K
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
[root@c7client images]#

The same if I create a volume with a backing file from virt-manager (not important if this is 0.10 or 1.1):

[root@c7client images]# qemu-img info zzz4.qcow2
image: zzz4.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
backing file: /var/lib/libvirt/images/zzz2.qcow2
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: true
[root@c7client images]#

But I don't know if internally virt-manager uses virsh or qemu-img actually....

My tests with:
libvirt-client-3.2.0-14.el7_4.9.x86_64
virt-manager-1.4.1-7.el7.noarch

The same default to 0.10 format seems true with virsh from Fedora 27 and libvirt-client-3.7.0-4.fc27.x86_64

Gianluca