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@whitehole ~]# virsh vol-create-as default zzz.qcow2 1G --format qcow2 Vol zzz.qcow2 created [root@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@whitehole ~]# file /var/lib/libvirt/images/zzz.qcow2 /var/lib/libvirt/images/zzz.qcow2: QEMU QCOW2 Image (v2), 1073741824 bytes # snapshot creation [root@whitehole ~]# virsh snapshot-create-as zzz --name zsnap1 --disk-only Domain snapshot zsnap1 created [root@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@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@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8