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

[Peter Krempa]

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.
-------------- 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/20190517/953039e8/attachment-0001.sig>