On Thu, Jun 06, 2019 at 08:35:15 -0500, Eric Blake wrote:
On 6/6/19 7:51 AM, Peter Krempa wrote:
> On Wed, Jun 05, 2019 at 22:01:08 -0500, Eric Blake wrote:
>> Add two capabilities for testing features required for the upcoming
>> virDomainBackupBegin: use block-dirty-bitmap-merge as the generic
>> witness of bitmap support needed for checkpoints (since all of the
>> bitmap management functionalities were finalized in the same qemu 4.0
>> release), and the bitmap parameter to nbd-server-add for pull-mode
>> backup support. Even though both capabilities are likely to be
>> present or absent together (that is, it is unlikely to encounter a
>> qemu that backports only one of the two), it still makes sense to keep
>> two capabilities as the two uses are orthogonal (full backups don't
>> require checkpoints, push mode backups don't require NBD bitmap
>> support, and checkpoints can be used for more than just incremental
>> backups).
>>
>> Signed-off-by: Eric Blake <eblake(a)redhat.com>
>> ---
>> src/qemu/qemu_capabilities.h | 4 ++++
>> src/qemu/qemu_capabilities.c | 6 ++++++
>> tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml | 2 ++
>> tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 2 ++
>> tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml | 2 ++
>> tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml | 2 ++
>> tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 2 ++
>> tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml | 2 ++
>> 8 files changed, 22 insertions(+)
>
> So the code looks good to me, but we need to clarify one thing before
> ACK.
>
> Is there anything that would change libvirt's behaviour incompatibly if
> these are specified? In some cases these also imply a libvirt behaviour
> change (e.g. different command line) and thus not pushing those in the
> same release as the implementation might cause problems.
So far, the only things that depend on the capabilities are the new code
additions for checkpoints and pull-mode backups; existing libvirt.git
should have no change in behavior whether or not the capabilities are
detected.
ACK in that case. If we don't modify the behaviour incompatibly after
the rest of the code is pushed this is safe to do.