13.05.2020 04:16, Eric Blake wrote:
Include actions for --add, --remove, --clear, --enable, --disable, and
--merge (note that --clear is a bit of fluff, because the same can be
accomplished by removing a bitmap and then adding a new one in its
place, but it matches what QMP commands exist). Listing is omitted,
because it does not require a bitmap name and because it was already
possible with 'qemu-img info'. A single command line can play one or
more bitmap commands in sequence on the same bitmap name (although all
added bitmaps share the same granularity, and and all merged bitmaps
come from the same source file). Merge defaults to other bitmaps in
the primary image, but can also be told to merge bitmaps from a
distinct image.
While this supports --image-opts for the file being modified, I did
not think it worth the extra complexity to support that for the source
file in a cross-file merges. Likewise, I chose to have --merge only
take a single source rather than following the QMP support for
multiple merges in one go (although you can still use more than one
--merge in the command line); in part because qemu-img is offline and
therefore atomicity is not an issue.
Upcoming patches will add iotest coverage of these commands while
also testing other features.
Signed-off-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Max Reitz <mre...@redhat.com>
I'm sorry for asking it only now on v4.. But still. Why do we need it? We can
instead run qemu binary (or even new qemu-storage-daemon) and just use existing
qmp commands. Is there a real benefit in developing qemu-img, maintaining two
interfaces for the same thing? Of-course, just run qmp commands from terminal
is a lot less comfortable than just a qemu img command.. But may be we need
some wrapper, which make it simple to run one qmp command on an image?
It's simple to make a python wrapper working like
qemu-qmp block-dirty-bitmap-add '{node: self, name: bitmap0, persistent: true}'
/path/to/x.qcow2
--
Best regards,
Vladimir
