[libvirt] [PATCH] Recheck disk backing chains after snapshot
John Ferlan
jferlan at redhat.com
Mon Apr 28 13:01:20 UTC 2014
On 04/25/2014 09:13 AM, Jiri Denemark wrote:
> When a snapshot operation finishes we have to recheck the backing chain
> of all disks involved in the snapshot. And we need to do that even if
> the operation failed because some of the disks might have changed if
> QEMU did not support transactions.
>
> Signed-off-by: Jiri Denemark <jdenemar at redhat.com>
> ---
>
> Notes:
> - BlockRebase and BlockCommit already recheck the backing chain when we
> get an event about a completed block job (in qemuProcessHandleBlockJob)
>
> src/qemu/qemu_driver.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
FYI: This change fixes an issue that virt-test found over my
weekend run in the 'blockpull' test which was caused by 4/4 of
the addressing backing stores by index:
http://www.redhat.com/archives/libvir-list/2014-April/msg00823.html
Essentially the test sets things up via:
/usr/bin/virsh snapshot-create-as virt-tests-vm1 snapshot1 snap1-desc --disk-only --atomic --no-metadata vda,snapshot=external,file=/home/virt-test/tmp/jeos-20-64.snap1
/usr/bin/virsh snapshot-create-as virt-tests-vm1 snapshot2 snap2-desc --disk-only --atomic --no-metadata vda,snapshot=external,file=/home/virt-test/tmp/jeos-20-64.snap2
/usr/bin/virsh snapshot-create-as virt-tests-vm1 snapshot3 snap3-desc --disk-only --atomic --no-metadata vda,snapshot=external,file=/home/virt-test/tmp/jeos-20-64.snap3
Then does (in different passes):
/usr/bin/virsh blockpull virt-tests-vm1 vda --wait --verbose
/usr/bin/virsh blockpull virt-tests-vm1 vda --wait --verbose --base /home/virt-test/tmp/jeos-20-64.snap2
/usr/bin/virsh blockpull virt-tests-vm1 vda --wait --verbose --base /home/virt-test/tmp/jeos-20-64.snap1
/usr/bin/virsh blockpull virt-tests-vm1 vda --wait --verbose --timeout 1
/usr/bin/virsh blockpull virt-tests-vm1 vda --wait --verbose --timeout 1 --base /home/virt-test/tmp/jeos-20-64.snap2
/usr/bin/virsh blockpull virt-tests-vm1 vda --wait --verbose --timeout 1 --base /home/virt-test/tmp/jeos-20-64.snap1
Without this patch applied, the blockpull's w/ --base supplied fail
with either:
could not find image '/home/virt-test/tmp/jeos-20-64.snap2' in chain for '/home/virt-test/tmp/jeos-20-64.snap3'
or
could not find image '/home/virt-test/tmp/jeos-20-64.snap1' in chain for '/home/virt-test/tmp/jeos-20-64.snap3'
John
FWIW: The weekend run I had w/ virt-test against recent upstream
changes was quite successful. There's still an issue or two to
resolve regarding how capacity is checked, but the recent storage
changes haven't caused regressions.
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 67ba487..492fcc1 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -12942,6 +12942,7 @@ qemuDomainSnapshotCreateDiskActive(virQEMUDriverPtr driver,
> bool persist = false;
> bool reuse = (flags & VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT) != 0;
> virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
> + virErrorPtr orig_err = NULL;
>
> if (!virDomainObjIsActive(vm)) {
> virReportError(VIR_ERR_OPERATION_INVALID,
> @@ -13033,6 +13034,17 @@ qemuDomainSnapshotCreateDiskActive(virQEMUDriverPtr driver,
> }
>
> cleanup:
> + /* recheck backing chains of all disks involved in the snapshot */
> + orig_err = virSaveLastError();
> + for (i = 0; i < snap->def->ndisks; i++) {
> + if (snap->def->disks[i].snapshot == VIR_DOMAIN_SNAPSHOT_LOCATION_NONE)
> + continue;
> + qemuDomainDetermineDiskChain(driver, vm, vm->def->disks[i], true);
> + }
> + if (orig_err) {
> + virSetError(orig_err);
> + virFreeError(orig_err);
> + }
>
> if (ret == 0 || !virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_TRANSACTION)) {
> if (virDomainSaveStatus(driver->xmlopt, cfg->stateDir, vm) < 0 ||
>
More information about the libvir-list
mailing list