The issue about adding multipath device's targets into qemu-pr-helper's namespace
Michal Privoznik
mprivozn at redhat.com
Tue Jul 14 14:38:16 UTC 2020
On 7/14/20 3:41 PM, Lin Ma wrote:
> Hi all,
>
> I have a namespace question about passthrough disk(multipath device).
> In case of enabling namespace and cgroups in qemu.conf, The target(s) of
> the
> multipath device won't be added into qemu-pr-helper's namespace under
> certain
> situation, It causes the PERSISTENT RESERVE command failure in guest.
>
Yeah, this is expected. I mean, the failure is expected if not all
devices are added to the namespace.
> While user starts a vm,
> To build namespace, The qemuDomainSetupDisk() will be invoked via
> threadA(this
> thread id will be the qemu's pid),
> To build cgroup, The qemuSetupImagePathCgroup() will be invoked via
> threadB.
>
> Both of the functions invoke the virDevMapperGetTargets() trying to parse a
> multipath device to target paths string, Then fill the targetPaths[].
>
> The issue I experienced is:
> After libvirtd started, Everything works well for the first booted vm
> which has
> the passthrough multipath device.
> But If I shut it down & start it again, OR keep it running & start
> another vm
> which has other passthrough multipath device, Then the target(s) of the
> fresh
> started vm won't be added into the related qemu-pr-helper's namespace
> and it
> causes PERSISTENT RESERVE command failure in the corresponding guest.
> I digged into code, In this situation, The targetPaths[] in
> qemuDomainSetupDisk()
> won't be filled, it keeps NULL after virDevMapperGetTargets() returns.
> The virDevMapperGetTargets doesn't fill targetPaths[] because the
> dm_task_run()
> of libdevmapper returns 0 with errno 9(Bad file descriptor).
> So far, I don't understand why the dm_task_run() return 0 in this
> situation.
> BTW, The virDevMapperGetTargets() can always successfully fill the
> targetPaths[]
> in qemuSetupImagePathCgroup().
What is your libvirt version? I've merged a fix for something similar
not a long ago: v6.5.0-rc1~190
Can you please check v6.5.0?
Michal
More information about the libvir-list
mailing list