11.04.2018 16:56, Eric Blake wrote:
On 04/03/2018 07:01 AM, Nikolay Shirokovskiy wrote:
Hi, all.
This is another RFC on pull backup API. This API provides means to read domain
disks in a snapshotted state so that client can back them up as well as means
to write domain disks to revert them to backed up state. The previous version
of RFC is [1]. I'll also describe the API implementation details to shed light
on misc qemu dirty bitmap commands usage.
Thanks for such a detailed message! It's got enough that I want to
spend some time thinking about the implications, but this is an early
reply to let you know I'm at least working on it now.
The first thing that caught my eye:
Here is a list of bitmap commands used in implementation but not yet in upstream (AFAIK).
x-vz-block-dirty-bitmap-remove
we have command block-dirty-bitmap-remove in qemu. We don't have
transaction support,
but it is hard to implement it, because we need to protect from
operations on same bitmap in same
transaction, so, we decided to not do it, Nikolay?
x-vz-block-dirty-bitmap-merge
x-vz-block-dirty-bitmap-disable
x-vz-block-dirty-bitmap-enable (not in the examples; used when removing most recent checkpoint)
they are in
[PATCH for-2.12 0/4] qmp dirty bitmap API
https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg02281.html
(long discussion)
and, I've already started v2 (preliminary refactoring):
[PATCH 0/7] Dirty bitmaps fixing and refactoring
https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg06568.html
(mostly not reviewed)
x-vz-nbd-server-add-bitmap
it is in
[PATCH for-2.13 0/4] NBD export bitmaps
http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg05701.html
(reviewed, I need to respin)
How close are we to having upstream implementations of any of those
commands? If not, what are their specifications? Libvirt is very
hesitant to add code that depends on a qemu x-* command, but if we can
get the actual command into qemu.git without the x-* prefix, it is
easier to justify libvirt adding the API even if qemu 2.13 is not yet
released.
--
Best regards,
Vladimir
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
