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@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; }