Dear All, using CentOS 7.2.1511, and libvirt from ovirt repositories (currently 1.2.17-13.el7_2.5, but without otherwise using ovirt) I am regularly backing up my VMs which are on qcow2 files. In general, I am trying to follow http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit A typical backup script would be #!/bin/bash dt=`date +%y%m%d` if virsh dominfo dockers10a | grep -q -E '^Status: *laufend|^State: *running' then virsh snapshot-create-as --domain dockers10a dockers10a --diskspec vda,file=/home/dockers10asnap.qcow2 --disk-only --no-metadata --atomic cp /kvm01/dockers10a.qcow2 /backup/dockers10a$dt.qcow2 virsh blockcommit dockers10a vda --active --verbose --pivot virsh snapshot-delete dockers10a dockers10a rm /home/dockers10asnap.qcow2 fi I am fully aware that the third line from the end "virsh snapshot-delete ..." will fail under regular circumstances. It is just there as a precaution to delete unnecessary snapshots should a previous backup have failed. For some time, I am noticing that from time to time backup fails in the way that the xml definition file of the VM backed up keeps the temporary file (in the example above /home/dockers10asnap.qcow2) as the source file. Then, at least upon rebooting the host, it will be unable to restart the VM. In addition, lots of other troubles can arise (following backups failing, storage issues). I am using a similar setup on four hosts. It seems that the better the resources of the host are, the lower the likelihood of the problem occurring - but that cannot be an acceptable state. Can someone please point me to how to avoid this? Regards, Michael Schefczyk
Am 26.07.16 um 10:25 schrieb Prof. Dr. Michael Schefczyk:> Dear All, > > using CentOS 7.2.1511, and libvirt from ovirt repositories (currently 1.2.17-13.el7_2.5, but without otherwise using ovirt) I am regularly backing up my VMs which are on qcow2 files. In general, I am trying to follow http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit > > A typical backup script would be > > #!/bin/bash > dt=`date +%y%m%d` > if virsh dominfo dockers10a | grep -q -E '^Status: *laufend|^State: *running' > then > virsh snapshot-create-as --domain dockers10a dockers10a --diskspec vda,file=/home/dockers10asnap.qcow2 --disk-only --no-metadata --atomic > cp /kvm01/dockers10a.qcow2 /backup/dockers10a$dt.qcow2 > virsh blockcommit dockers10a vda --active --verbose --pivot > virsh snapshot-delete dockers10a dockers10a > rm /home/dockers10asnap.qcow2 > fi > > I am fully aware that the third line from the end "virsh snapshot-delete ..." will fail under regular circumstances. It is just there as a precaution to delete unnecessary snapshots should a previous backup have failed. > > For some time, I am noticing that from time to time backup fails in the way that the xml definition file of the VM backed up keeps the temporary file (in the example above /home/dockers10asnap.qcow2) as the source file. Then, at least upon rebooting the host, it will be unable to restart the VM. In addition, lots of other troubles can arise (following backups failing, storage issues). > > I am using a similar setup on four hosts. It seems that the better the resources of the host are, the lower the likelihood of the problem occurring - but that cannot be an acceptable state. > > Can someone please point me to how to avoid this?Here is what i do. I check the VM if it is running from a snapshot first. if [[ $(virsh domblklist vmmachinename) = *weekly* ]]; then echo "Found activ snapshot vmmachinename" | mail -s "Found activ snapshot vmmachinename" emailaddress else cheers t.> Regards, > > Michael Schefczyk > > > > > > _______________________________________________ > libvirt-users mailing list > libvirt-users@redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-users >
Dear Thomas, Thank you very much - that is a very helpful diagnostic method / alarm bell! Further investigating my issue, I determined that I often get "error: block copy still active: disk 'vda' not ready for pivot yet". The more limited the hardware is, the higher the likelihood, I think. The underlying storage is gluster and I think that this is due to locking issues in slower environments. Therefore, I added a "sleep" command ahead of the "blockcommit" command. That does seem to be OK as a workaround in most cases. Nevertheless, I am not sure if there are other causes as well and if there are better ways to prevent this issue as the sleep command is probably not the most elegant way. Regards, Michael -----Ursprüngliche Nachricht----- Von: libvirt-users-bounces@redhat.com [mailto:libvirt-users-bounces@redhat.com] Im Auftrag von Thomas Stein Gesendet: Dienstag, 26. Juli 2016 10:53 An: 'libvirt-users@redhat.com' <libvirt-users@redhat.com> Betreff: Re: [libvirt-users] Live Disk Backup Am 26.07.16 um 10:25 schrieb Prof. Dr. Michael Schefczyk:> Dear All, > > using CentOS 7.2.1511, and libvirt from ovirt repositories (currently > 1.2.17-13.el7_2.5, but without otherwise using ovirt) I am regularly > backing up my VMs which are on qcow2 files. In general, I am trying to > follow > http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit > > A typical backup script would be > > #!/bin/bash > dt=`date +%y%m%d` > if virsh dominfo dockers10a | grep -q -E '^Status: *laufend|^State: *running' > then > virsh snapshot-create-as --domain dockers10a dockers10a --diskspec > vda,file=/home/dockers10asnap.qcow2 --disk-only --no-metadata --atomic > cp /kvm01/dockers10a.qcow2 /backup/dockers10a$dt.qcow2 virsh > blockcommit dockers10a vda --active --verbose --pivot virsh > snapshot-delete dockers10a dockers10a rm /home/dockers10asnap.qcow2 fi > > I am fully aware that the third line from the end "virsh snapshot-delete ..." will fail under regular circumstances. It is just there as a precaution to delete unnecessary snapshots should a previous backup have failed. > > For some time, I am noticing that from time to time backup fails in the way that the xml definition file of the VM backed up keeps the temporary file (in the example above /home/dockers10asnap.qcow2) as the source file. Then, at least upon rebooting the host, it will be unable to restart the VM. In addition, lots of other troubles can arise (following backups failing, storage issues). > > I am using a similar setup on four hosts. It seems that the better the resources of the host are, the lower the likelihood of the problem occurring - but that cannot be an acceptable state. > > Can someone please point me to how to avoid this?Here is what i do. I check the VM if it is running from a snapshot first. if [[ $(virsh domblklist vmmachinename) = *weekly* ]]; then echo "Found activ snapshot vmmachinename" | mail -s "Found activ snapshot vmmachinename" emailaddress else cheers t.> Regards, > > Michael Schefczyk > > > > > > _______________________________________________ > libvirt-users mailing list > libvirt-users@redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-users >_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users