The code preparing data for creating/attaching the target image of block
copy didn't use the correct reference to the existing backing chain in
case when the copy should inherit it. This meant that qemu actually
opened a second copy of the chain and operated on that.
This would de-sync qemu from libvirt's view of node names. Luckily this
is only hypothetical at this point since it happens only when -blockdev
is enabled.
Fix it by passing 'mirrorBacking' which has the proper data as the
backing store when calling
qemuBuildStorageSourceChainAttachPrepareBlockdevTop.
Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
---
src/qemu/qemu_driver.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index df677d8f4c..1fa8fe8391 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -18544,10 +18544,12 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm,
* new image must refer to it in the metadata */
mirrorBacking = disk->src->backingStore;
}
+ } else {
+ mirrorBacking = mirror->backingStore;
}
if (!(crdata = qemuBuildStorageSourceChainAttachPrepareBlockdevTop(mirror,
- mirror->backingStore,
+ mirrorBacking,
priv->qemuCaps)))
goto endjob;
}
--
2.21.0
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
