[libvirt] [PATCH 4/8] qemu: hotplug: Prepare disk source for media changing

[John Ferlan]

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