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 <pkre...@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 > >