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@xxxxxxxxxx> > >> --- > >> 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.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
