The issue about adding multipath device's targets into qemu-pr-helper's namespace

Lin Ma lma at
Wed Jul 15 03:35:24 UTC 2020

On 2020-07-14 14:38, Michal Privoznik wrote:
> 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?

The libvirt version I used in the tests is git master.
The sure thing is that the multipath devices I used are valid and 

In the test A or the test B, Everytime we restart libvirtd, The issue 
won't happen for
the first booted vm.

In other words, The target of multipath device can be parsed & added to 
namespace for the first booted vm.

As long as libvirtd once invoked 
to successfully parse any valid multipath device,
 From then on, The 
returns 0 with errno=9 when parsing any valid multipath device.

BTW, I ran the same tests on kernel 4.12 and kernel 5.6, Got the same 
test results.


More information about the libvir-list mailing list