On 9/27/18 11:09 AM, Peter Krempa wrote:
The disk storage source needs to be prepared if we want to use
-blockdev
or secrets for the new media image.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_hotplug.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 3043b3257b..1ec696e2aa 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -729,6 +729,7 @@ qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver,
virStorageSourcePtr newsrc,
bool force)
{
+ virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
qemuDomainObjPrivatePtr priv = vm->privateData;
virStorageSourcePtr oldsrc = disk->src;
int ret = -1;
@@ -736,6 +737,9 @@ qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver,
disk->src = newsrc;
+ if (qemuDomainPrepareDiskSource(disk, priv, cfg) < 0)
+ goto cleanup;
+
"Assuming" this becomes passing "@newdisk" along to
qemuDomainPrepareDiskSource, then this would seem to be fine.
Compared to the order in AttachDiskGeneric, should this go under
PrepareDiskAccess? And since qemuAssignDeviceDiskAlias doesn't use the
disk->src, then it doesn't need to be called - whether you want to note
that or not, IDC.
I didn't go chasing into qemuHotplugAttachManagedPR to determine whether
perhaps that failure should have "undone" qemuHotplugPrepareDiskAccess,
but looking at qemuDomainAttachDiskGeneric, I think the answer may be
yes. IOW: Perhaps an error label would be needed.
John
if (qemuHotplugPrepareDiskAccess(driver, vm, disk, newsrc,
false) < 0)
goto cleanup;
@@ -770,6 +774,7 @@ qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver,
if (oldsrc)
disk->src = oldsrc;
+ virObjectUnref(cfg);
return ret;
}