[Question] Which qcow2 options could be inherited to snapshot/blockcopy?

[Gionatan Danti]

Il 2022-11-21 10:30 Peter Krempa ha scritto:
> In regards to the 'compat' option in terms of snapshots/blockcopy, we
> don't set it and thus use the qemu default. Since both operations 
> create
> a new image with an existing qemu instance, the default new qemu format
> is okay.

Hi, some idea on why creating a qcow2 volume and snapshotting it via a 
backing file results in two qcow2 files with different format (v2 vs 
v3)? Example below:

# volume creation
[root at whitehole ~]# virsh vol-create-as default zzz.qcow2 1G --format 
qcow2
Vol zzz.qcow2 created

[root at whitehole ~]# qemu-img info /var/lib/libvirt/images/zzz.qcow2
image: /var/lib/libvirt/images/zzz.qcow2
file format: qcow2
virtual size: 1 GiB (1073741824 bytes)
disk size: 16.5 KiB
cluster_size: 65536
Format specific information:
     compat: 0.10
     compression type: zlib
     refcount bits: 16

[root at whitehole ~]# file /var/lib/libvirt/images/zzz.qcow2
/var/lib/libvirt/images/zzz.qcow2: QEMU QCOW2 Image (v2), 1073741824 
bytes

# snapshot creation
[root at whitehole ~]# virsh snapshot-create-as zzz --name zsnap1 
--disk-only
Domain snapshot zsnap1 created

[root at whitehole ~]# qemu-img info /var/lib/libvirt/images/zzz.zsnap1
image: /var/lib/libvirt/images/zzz.zsnap1
file format: qcow2
virtual size: 1 GiB (1073741824 bytes)
disk size: 16.5 KiB
cluster_size: 65536
backing file: /var/lib/libvirt/images/zzz.qcow2
backing file format: qcow2
Format specific information:
     compat: 1.1
     compression type: zlib
     lazy refcounts: false
     refcount bits: 16
     corrupt: false
     extended l2: false

[root at whitehole ~]# file /var/lib/libvirt/images/zzz.zsnap1
/var/lib/libvirt/images/zzz.zsnap1: QEMU QCOW2 Image (v3), has backing 
file (path /var/lib/libvirt/images/zzz.qcow2), 1073741824 bytes

Regards.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8