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

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