On 2019-05-17 09:36, Peter Krempa wrote:
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.)
Yes it happens since 5.1 I guess? Maybe even 5.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
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:
Thank you. Will do so.
cheers
t.
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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
