Re: [libvirt] surprising <backingStore type='file'> setting in domain.xml

On Thu, May 16, 2019 at 17:20:05 +0200, Thomas Stein wrote: > Hello all. Hi, > My currently used versions: libvirt-5.2.0 and qemu-4.0.0. I don't think this is a regression, but it will not hurt to ask. Is this a new problem which was not observed before? (I'm asking because I was messing with the blockjob code lately.)

> > Here is my problem. I'm struggeling since a few weeks with a strange > behaviour by either qemu or libvirt. After a reboot of This is definitely a libvirt problem ... > the hardware node the $domain.xml contains suddenly a backingStore > setting > which was not there before reboot. > Something like that: > > <devices> > <emulator>/usr/bin/qemu-system-x86_64</emulator> > <disk type='file' device='disk'> > <driver name='qemu' type='qcow2'/> > <source > file='/var/lib/libvirt/shinymail/shinymail_weekly.qcow2-2019-05-15'/> > <backingStore type='file'> > <format type='qcow2'/> > <source file='/var/lib/libvirt/images/shinymail.qcow2'/> > </backingStore> > <target dev='vda' bus='virtio'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x07' > function='0x0'/> > </disk> > ... > > This obviousely happens after a backup has been running. The Backup > Script > looks like this: > > <snip> > virsh snapshot-create-as --domain shinymail weekly --diskspec > vda,file=/var/lib/libvirt/shinymail/shinymail_weekly.qcow2-$(date > +%Y-%m-%d) > --disk-only --atomic --no-metadata So the problem is that this command modifies both the running configuration and the inactive configuration (which can be accessed by virsh dumpxml --inactive, while the VM is running) .. > > cp ... > > virsh blockcommit shinymail vda --active --verbose --pivot > <snip> ... while this only modifies the running configuration as we usually don't have enough metadata stored to be able to undo the inactive (next-boot) config as well. Since snapshot-create-as recorded the overlay in the next boot config and blockcommit did not undo it, the next time you boot it we will attempt to start the VM back with the overlay image which was actually merged back. If you'd delete it after blockcommit, the startup would fail completely. This unfortunate design fail of those two APIs originates from tunnel vision while implementing them as that workflow is usually used with "transient" VMs (VMs which don't have a inactive config in libvirt and vanish after being turned off) and thus don't have a problem with the inactive configuration because the management app recreates it. While there are efforts to make this work properly going on currently, you might want to use the following workaround:

virsh dumpxml --inactive --domain shinymail > inactive.xml virsh snapshot-create ..... cp ... virsh blockcommit .... virsh define inactive.xml rm /var/lib/libvirt/shinymail/shinymail_weekly.... rm inactive.xml (unfortunately while 'blockcommit' has --delete option it was never made functional, so you have to delete the overlay manually). Since the overlay was merged it makes no sense to keep it around. Thanks for reporting this problem though, I'll try addressing it with my disk storage handling rework.