Description of problem: [incremental_backup] "--size" doesn't work for checkpoint-dumpxml Version-Release number of selected component (if applicable): libvirt-6.0.0-9.module+el8.2.0+5957+7ae8988e.x86_64 How reproducible: 100% Steps to Reproduce: 1. create a backup for a vm [root@hp-dl320eg8-05 pull]# cat backup_sock_full.xml <domainbackup mode='pull'> <server transport="unix" socket="/tmp/nbd.socket"/> <disks> <disk name='vda' backup='yes' type='block'> <scratch dev='/dev/sdd'/> </disk> </disks> </domainbackup> [root@hp-dl320eg8-05 pull]# cat checkpoint_sock_full.xml <domaincheckpoint> <name>check_full</name> <disks> <disk name='vda' checkpoint='bitmap'/> </disks> </domaincheckpoint> [root@hp-dl320eg8-05 pull]# virsh backup-begin vm1 backup_sock_full.xml checkpoint_sock_full.xml Backup started [root@hp-dl320eg8-05 pull]# virsh domjobabort vm1 [root@hp-dl320eg8-05 pull]# virsh checkpoint-list vm1 Name Creation Time ----------------------------------------- check_full 2020-03-18 05:51:00 -0400 2. add --size to dumpxml vm's checkpoint, got an error [root@hp-dl320eg8-05 pull]# virsh checkpoint-dumpxml vm1 check_full --size error: unsupported flags (0x4) in function qemuCheckpointGetXMLDesc Actual results: as above Expected results: --size should work
Comment 0 is a normal backup scenario, we can use pure checkpoint scenario to reproduce this for simplicity [root@hp-dl320eg8-05 pull]# virsh checkpoint-create-as vm1 check_full --diskspec vda,checkpoint=bitmap,bitmap=check_full Domain checkpoint check_full created [root@hp-dl320eg8-05 pull]# virsh checkpoint-dumpxml vm1 check_full --size error: unsupported flags (0x4) in function qemuCheckpointGetXMLDesc
Fixed upstream: commit eafd3b3a21a6a194a78f8f4d2aaa03003ef9650d Author: Peter Krempa <pkrempa> Date: Thu Jul 2 16:06:26 2020 +0200 checkpoint: Mention that VIR_DOMAIN_CHECKPOINT_XML_SIZE is expensive and stale Data is valid only when queried as guest writes may increase the backup size. Signed-off-by: Peter Krempa <pkrempa> Reviewed-by: Eric Blake <eblake> commit b9c24236fa42a808d768debd86e716d919512919 Author: Peter Krempa <pkrempa> Date: Wed Jul 1 16:58:37 2020 +0200 qemu: checkpoint: Implement VIR_DOMAIN_CHECKPOINT_XML_SIZE Introduce code which merges the appropriate bitmaps and queries the final size of the backup, so that we can print the XML with size information. Signed-off-by: Peter Krempa <pkrempa> Reviewed-by: Eric Blake <eblake> commit a94997c4769ac376fc1fcf7111c6d8f5898579ea Author: Peter Krempa <pkrempa> Date: Wed Jul 1 16:58:29 2020 +0200 conf: checkpoint: Add a flag storing whether disk 'size' is valid Avoid printing '0' size in case when we weren't able to determine the backup size by adding a flag whether the size is valid and interlock printing of the field according to the flag. Signed-off-by: Peter Krempa <pkrempa> Reviewed-by: Eric Blake <eblake> commit 459a60823e3f744239732c00bdd7b87a0252a4d2 Author: Peter Krempa <pkrempa> Date: Thu Jun 25 14:47:25 2020 +0200 docs: checkpoint: Convert XML documentation to RST Switch to the new format for easier extension. Signed-off-by: Peter Krempa <pkrempa> Reviewed-by: Eric Blake <eblake>
test with: libvirt-6.6.0-2.module+el8.3.0+7567+dc41c0a9.x86_64 result: PASS Steps: 1. Prepare a clear qcow2 image for vm vdb [root@dell-per730-67 ~]# qemu-img create -f qcow2 /var/lib/libvirt/images/vdb.qcow2 1G Formatting '/var/lib/libvirt/images/vdb.qcow2', fmt=qcow2 cluster_size=65536 compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 [root@dell-per730-67 ~]# virsh domblklist vm1 Target Source -------------------------------------------------------- vda /var/lib/libvirt/images/jeos-27-x86_64.qcow2 vdb /var/lib/libvirt/images/vdb.qcow2 [root@dell-per730-67 ~]# virsh start vm1 Domain vm1 started 2. create a checkpoint=ck1 [root@dell-per730-67 ~]# virsh checkpoint-create-as vm1 ck1 Domain checkpoint ck1 created 3. write 1M data in vm's vdb [root@dell-per730-67 ~]# virsh console vm1 [root@localhost ~]# dd if=/dev/urandom of=/dev/vdb bs=1M seek=20 count=1; sync 1+0 records in 1+0 records out 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00974414 s, 108 MB/s 4. check the vdb's size info with "checkpoint-dumpxml --size" [root@dell-per730-67 ~]# virsh checkpoint-dumpxml vm1 ck1 --size --no-domain <domaincheckpoint> <name>ck1</name> <creationTime>1597203995</creationTime> <disks> <disk name='vda' checkpoint='bitmap' bitmap='ck1' size='851968'/> <disk name='vdb' checkpoint='bitmap' bitmap='ck1' size='1048576'/> </disks> </domaincheckpoint> <====== 1048576B = 1MB, it's correct 5. create another checkpoint=ck2 [root@dell-per730-67 ~]# virsh checkpoint-create-as vm1 ck2 Domain checkpoint ck2 created 6. create another 1M data in vdb [root@localhost ~]# dd if=/dev/urandom of=/dev/vdb bs=1M seek=30 count=1; sync 1+0 records in 1+0 records out 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00823651 s, 127 MB/s 7. check the vdb's size info with "checkpoint-dumpxml --size", since checkpoint=ck1 [root@dell-per730-67 ~]# virsh checkpoint-dumpxml vm1 ck1 --size --no-domain <domaincheckpoint> <name>ck1</name> <creationTime>1597203995</creationTime> <disks> <disk name='vda' checkpoint='bitmap' bitmap='ck1' size='851968'/> <disk name='vdb' checkpoint='bitmap' bitmap='ck1' size='2097152'/> </disks> </domaincheckpoint> <=== now, the vdb's delta size since ck1 is 2097152B = 2MB, it's correct 8. check the vdb's size info with "checkpoint-dumpxml --size", since checkpoint=ck2 [root@dell-per730-67 ~]# virsh checkpoint-dumpxml vm1 ck2 --size --no-domain <domaincheckpoint> <name>ck2</name> <parent> <name>ck1</name> </parent> <creationTime>1597204239</creationTime> <disks> <disk name='vda' checkpoint='bitmap' bitmap='ck2' size='0'/> <disk name='vdb' checkpoint='bitmap' bitmap='ck2' size='1048576'/> </disks> </domaincheckpoint> <=== now, the vdb's delta size since ck2 is 1048576B = 1MB, it's correct
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (virt:8.3 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:5137