[Question] Which qcow2 options could be inherited to snapshot/blockcopy?
Hi, I'm trying to find out which qcow2 options could be inherited to snapshot/blockcopy and then test them. >From https://github.com/qemu/qemu/blob/master/qapi/block-core.json#L4720 we can know all the qcow2 options. As far as I know, size, cluster_size and extended-l2 have already been implemented. So I'm curious that: 1) What are the current status and future plans of other options? Like compat option. 2) Also whether the vol-clone can cover all options? Thank you very much. And please help to correct me if I have something wrong. Best Regards, Meina Li
On Mon, Nov 21, 2022 at 11:22:40 +0800, Meina Li wrote:
Hi,
I'm trying to find out which qcow2 options could be inherited to snapshot/blockcopy and then test them.
From https://github.com/qemu/qemu/blob/master/qapi/block-core.json#L4720 we can know all the qcow2 options. As far as I know, size, cluster_size and extended-l2 have already been implemented. So I'm curious that: 1) What are the current status and future plans of other options? Like compat option.
The 'size' option is needed obviously to have a correctly sized image. With 'cluster_size' and 'extended_l2' those options were identified as having potential performance implications and users actually wanting to tweak them for their images. Thus we inherit them. For anything else there wasn't any specific request or noting that it can have performance implications so they are omitted for now. 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. For the other options: - 'encrypt' and co. - encryption can be explicitly enabled via XML - 'data-file-raw' - not supported by libvirt, no plans for now - 'preallocation' - not implemented - some options don't make sense, e.g. full allocation for a snapshot - 'lazy-refcounts'/'refcount-bits' - not implemented, no plans - 'compression-type' - libvirt for now doesn't allow to use compression IIRC
2) Also whether the vol-clone can cover all options?
Note that 'vol-clone' uses qemu-img, so the logic is different there.
Thank you very much. And please help to correct me if I have something wrong.
Best Regards, Meina Li
Hi Peter, I can learn a lot from what you said. Thank you very much. Best Regards, Meina Li On Mon, Nov 21, 2022 at 5:30 PM Peter Krempa <pkrempa@redhat.com> wrote:
On Mon, Nov 21, 2022 at 11:22:40 +0800, Meina Li wrote:
Hi,
I'm trying to find out which qcow2 options could be inherited to snapshot/blockcopy and then test them.
From https://github.com/qemu/qemu/blob/master/qapi/block-core.json#L4720 we can know all the qcow2 options. As far as I know, size, cluster_size and extended-l2 have already been implemented. So I'm curious that: 1) What are the current status and future plans of other options? Like compat option.
The 'size' option is needed obviously to have a correctly sized image.
With 'cluster_size' and 'extended_l2' those options were identified as having potential performance implications and users actually wanting to tweak them for their images. Thus we inherit them.
For anything else there wasn't any specific request or noting that it can have performance implications so they are omitted for now.
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.
For the other options:
- 'encrypt' and co. - encryption can be explicitly enabled via XML - 'data-file-raw' - not supported by libvirt, no plans for now - 'preallocation' - not implemented - some options don't make sense, e.g. full allocation for a snapshot - 'lazy-refcounts'/'refcount-bits' - not implemented, no plans - 'compression-type' - libvirt for now doesn't allow to use compression IIRC
2) Also whether the vol-clone can cover all options?
Note that 'vol-clone' uses qemu-img, so the logic is different there.
Thank you very much. And please help to correct me if I have something wrong.
Best Regards, Meina Li
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
Il 2022-11-26 10:36 Gionatan Danti ha scritto:
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.
Hi all, anyone with some ideas/suggestions? 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
On Sun, Dec 11, 2022 at 20:36:26 +0100, Gionatan Danti wrote:
Il 2022-11-26 10:36 Gionatan Danti ha scritto:
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.
Hi all, anyone with some ideas/suggestions?
Hi, When creating a snapshot libvirt uses the qemu default for the created qcow2 image's version which is now v3. Do you have any specific use case for keeping them in v2 mode?
Il 2022-12-12 08:39 Peter Krempa ha scritto:
Hi,
When creating a snapshot libvirt uses the qemu default for the created qcow2 image's version which is now v3.
Do you have any specific use case for keeping them in v2 mode?
Hi, it really is the other way around: I am surprised virsh vol-create uses v2 rather than v3. Any reason for this difference? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8
participants (3)
-
Gionatan Danti -
Meina Li -
Peter Krempa