Re: [PATCH v5 05/11] qemu_ns: Allow /dev/mapper/control for PR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 04/23/2018 09:14 AM, Michal Privoznik wrote:
> If qemu-pr-helper is compiled with multipath support the first
> thing it does is open /dev/mapper/control. Since we're going
> to be running it inside qemu namespace we need to create it
> there. Unfortunately, we don't know if it was compiled with or
> without multipath so we have to create it anyway.
> 
> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
> ---
>  src/qemu/qemu_domain.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 53827d5396..5ccdeb8e3a 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -109,6 +109,7 @@ VIR_ENUM_IMPL(qemuDomainNamespace, QEMU_DOMAIN_NS_LAST,
>  #define PROC_MOUNTS "/proc/mounts"
>  #define DEVPREFIX "/dev/"
>  #define DEV_VFIO "/dev/vfio/vfio"
> +#define DEVICE_MAPPER_CONTROL_PATH "/dev/mapper/control"
>  
>  
>  struct _qemuDomainLogContext {
> @@ -10207,6 +10208,11 @@ qemuDomainSetupDisk(virQEMUDriverConfigPtr cfg ATTRIBUTE_UNUSED,
>              goto cleanup;
>      }
>  
> +    /* qemu-pr-helper might require access to /dev/mapper/control. */
> +    if (virStoragePRDefIsEnabled(disk->src->pr) &&
> +        qemuDomainCreateDevice(DEVICE_MAPPER_CONTROL_PATH, data, true) < 0)
> +        goto cleanup;
> +

This is from SetupAllDisks via qemuDomainBuildNamespace...  Does it or
could it matter that more than one disk would be doing this? Thus having
multiple entries?  Was too lazy to check.

>      ret = 0;
>   cleanup:
>      VIR_FREE(dst);
> @@ -11218,6 +11224,7 @@ qemuDomainNamespaceSetupDisk(virDomainObjPtr vm,
>      virStorageSourcePtr next;
>      const char **paths = NULL;
>      size_t npaths = 0;
> +    char *dmPath = NULL;
>      int ret = -1;
>  
>      if (!qemuDomainNamespaceEnabled(vm, QEMU_DOMAIN_NS_MOUNT))
> @@ -11234,11 +11241,18 @@ qemuDomainNamespaceSetupDisk(virDomainObjPtr vm,
>              goto cleanup;
>      }
>  
> +    /* qemu-pr-helper might require access to /dev/mapper/control. */
> +    if (virStoragePRDefIsEnabled(src->pr) &&
> +        (VIR_STRDUP(dmPath, DEVICE_MAPPER_CONTROL_PATH) < 0 ||
> +         VIR_APPEND_ELEMENT_COPY(paths, npaths, dmPath) < 0))
> +        goto cleanup;
> +

... similarly when we add/hotplug a disk we could be repeating that path.

If the duplication is OK or handled in some way that wasn't obvious,

Reviewed-by: John Ferlan <jferlan@xxxxxxxxxx>

If you need to adjust the logic to handle this specially, then obviously
I'd ask to wait for that OK.  I wonder if the @prDaemonRunning logic
added later on would suffice?

John

>      if (qemuDomainNamespaceMknodPaths(vm, paths, npaths) < 0)
>          goto cleanup;
>  
>      ret = 0;
>   cleanup:
> +    VIR_FREE(dmPath);
>      VIR_FREE(paths);
>      return ret;
>  }
> 

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux