Re: [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