[libvirt] [PATCH 2/4] backup: Add two new qemu capabilities

[Peter Krempa]

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 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190607/4a90b422/attachment-0001.sig>