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@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. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org