On Thu, May 21, 2020 at 2:40 PM Vladimir Sementsov-Ogievskiy <[email protected]> wrote: > > 21.05.2020 02:00, Nir Soffer wrote: > > On Thu, May 21, 2020 at 1:01 AM Eric Blake <[email protected]> wrote: > >> > >> It's useful to know how much space can be occupied by qcow2 persistent > >> bitmaps, even though such metadata is unrelated to the guest-visible > >> data. Report this value as an additional QMP field, present when > >> measuring an existing image and output format that both support > >> bitmaps. Update iotest 178 and 190 to updated output, as well as new > >> coverage in 190 demonstrating non-zero values made possible with the > >> recently-added qemu-img bitmap command. > >> > >> On the command-line side, 'qemu-img measure' gains a new --bitmaps > >> flag. When present, the bitmap size is rolled into the two existing > >> measures (or errors if either the source image or destination format > >> lacks bitmaps); when absent, there is never an error (for > >> back-compat), but the output will instead include a new line item for > >> bitmaps (which you would have to manually add), with that line being > >> omitted in the same cases where passing --bitmaps would error. > > > > Supporting 2 ways to measure, one by specifying --bitmaps, and another > > by adding bitmaps key is not a good idea. We really need one way. > > > > Each one has advantages. adding --bitmaps flag is consistent with > > "qemu-img convert" > > and future extensions that may require new flag, and adding "bitmaps" > > key is consistent > > with "qmeu-img info", showing bitmaps when they exist. > > > > Adding a "bitmaps" key has an advantage that we can use it to test if > > qemu-img > > supports measuring and copying bitmaps (since both features are expected to > > be delivered at the same time). So we can avoid checking --help learn about > > the capabilities. > > > > I'm ok with both options, can we have only one? > > Hi! What are your scenarios? Are you using qemu-img by hand, or it is used > from some management tool? For management tool, I'd recommend to use qmp > interface, which is a lot more strict, reliable and stable, and documented. > You just need to run qemu binary in stopped mode for it.
The use case is oVirt - it is a management system but it uses qemu-img to perform various operations, like copying disks around. The specific use case is cloning qcow2 image chain from one server to another, or cloning on the same server. In the case of qcow2 images on logical volumes, we need to create a large enough logical volume to copy an image, and for this we use "qemu-img measure". With the current patches we will be able to create large enough logical volume and copy the image data and the bitmps to the destination. qmp interface is nice but to use it we have to rewrite all the code using qemu-img to start qemu with the relevant disks and perform operation via qmp or via libvirt. This a huge rewrite and I'm not sure it's worth the effort. This approach also has limitations, for example using qemu-img we can copy disks in parallel on multiple hosts, while using libvirt and qemu will limit us to using one host since qemu takes locks that we control. Also using libvirt means that all new features take more time to complete since now we have a new layer between oVirt and qemu.
