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

(switched to libvirt-users as it seems to be more appropriate) On 2019-05-16 23:02, Eric Blake wrote:
On 5/16/19 10:20 AM, Thomas Stein wrote:
Hello all.
My currently used versions: libvirt-5.2.0 and qemu-4.0.0.
Here is my problem. I'm struggeling since a few weeks with a strange behaviour by either qemu or libvirt. After a reboot of 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'/>
Yes, this matches:
</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
the effects of this command.
Ultimately, I'm TRYING to get my new 'virsh domain-backup' command integrated into the next libvirt release, which has the advantage of performing a backup WITHOUT having to modify the <domain> XML. But until that happens, any time you use 'virsh snapshot-create-as' as part of a sequence for performing backups, you ARE modifying the <domain> XML, and if you want to revert to the external backup, or if...
Cool. Will it be in 5.4.0 already?
cp ...
virsh blockcommit shinymail vda --active --verbose --pivot <snip>
...blockcommit fails for whatever reason to undo the effects of 'snapshot-create-as' in creating a temporary overlay, then yes, you do have to worry about the temporary overlay being in the way, where you'll have to manually edit the <domain> definition to match the actual disk layouts you really want.
So you're saying blockcommit fails me somehow? What i'm asking myself is, why does this problem suddenly appear. It worked literally for years this way. thanks for your answer Eric. cheers t.
So after that "dmblklist shinymail" does show the right source file but after a reboot it tries to use the weekly snapshot again which leads to filesystem errors.
Someone has an idea what could cause such a behaviour?
participants (1)
-
Thomas Stein