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

[Thomas Stein]

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