libvirt users - Nov 2022 - [Question] Which qcow2 options could be inherited to snapshot/blockcopy?

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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20221121/7e6867a8/attachment.htm>

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