Description: [incremental_backup] Cannot backup to a RAW file (even for full backup). But this is mentioned in libvirt doc. Versions: libvirt-6.0.0-9.module+el8.2.0+5957+7ae8988e.x86_64 How reproducible: 100% Steps: 1. In libvirt-rhel/docs/formatbackup.html.in Or https://libvirt.org/formatbackup.html#BackupAttributes There is an example of backup's target driver type='raw' =============================== target Valid only for push mode backups, this is the primary sub-element that describes the file name of the backup destination, similar to the source sub-element of a domain disk. An optional sub-element driver can also be used, with an attribute type to specify a destination format different from qcow2. ... ... <domainbackup> <disks> <disk name='vda' backup='yes'/> <disk name='vdb' type='file'> <target file='/path/to/vdb.backup'/> <driver type='raw'/> </disk> <disk name='vdc' backup='no'/> </disks> </domainbackup> =============================== 2. Prepare a vm [root@hp-dl320eg8-05 push]# virsh domblklist vm1 Target Source -------------------------------------------------- vda /var/lib/libvirt/images/base_os.active vdb avocado-vt-pool/inc_test.qcow2 3. Prepare backup and checkpoint xml, and set target driver='raw' [root@hp-dl320eg8-05 push]# cat backup_push_raw.xml <domainbackup mode='push'> <disks> <disk name='vda' type='file'> <target file='/home/images/vda.full.backup'/> <driver type='raw'/> </disk> <disk name='vdb' backup='no'/> </disks> </domainbackup> [root@hp-dl320eg8-05 push]# cat checkpoint_push_full.xml <domaincheckpoint> <name>check_full</name> </domaincheckpoint> 4. Start the backup, failed. [root@hp-dl320eg8-05 push]# virsh backup-begin vm1 backup_push_raw.xml checkpoint_push_full.xml error: unsupported configuration: storage format 'raw' does not support backing store Actual result: Libvirt doc gave a sample with driver=raw, but actually it's not supported. Expected result: For full backup, maybe we should allow driver=raw, and forbid driver=raw for incremental backup? If raw is forbidden due to we cannot use the full backup file as backing file for incremental backup later, we may need to update to doc to avoid a confusing example using driver=raw.
Fixed upstream: commit 4aea6f42fe32175ce0cb9015913db536097130e4 Author: Peter Krempa <pkrempa> Date: Tue Mar 31 15:43:46 2020 +0200 qemu: backup: Fix handling of backing store for backup target images We always tried to install backing store for the image even if it didn't make sense, e.g. for a full backup into a raw image. Additionally we didn't record the backing file into the qcow2 metadata so the image itself contained the diff of data but reading from it would be incomplete as it depends on the backing image. This patch fixes both issues by carefully installing the correct backing file when appropriate and also recording it into the metadata when creating the image.
Test with: libvirt-6.5.0-1.module+el8.3.0+7323+d54bb644.x86_64 Result is: PASS Testcase: https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/libvirt/view/RHEL-8.3%20x86_64/job/libvirt-RHEL-8.3-runtest-x86_64-function-incremental_backup/4/testReport/rhel/incremental_backup/push_mode_original_disk_local_coldplug_disk_backup_to_raw_backup_to_block_positive_test/
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