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?
>