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

[Michal Prívozník]

On 7/15/20 5:35 AM, Lin Ma wrote:
> 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 
> functional.
> 
> 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 
> qemu-pr-helper's
> namespace for the first booted vm.
> 
> As long as libvirtd once invoked 
> qemuSetupImagePathCgroup()->virDevMapperGetTargetsImpl()
> to successfully parse any valid multipath device,
>  From then on, The 
> qemuDomainSetupDisk()->virDevMapperGetTargetsImpl()->dm_task_run()
> returns 0 with errno=9 when parsing any valid multipath device.

At this point I'm wondering whether we are using the API correctly.
If you disable namespaces, then CGroups still need to know the targets 
and will query dm. Does that work?

The aim is to do what 'dmsetup deps' does. Once you reach the error 
state - does that command work?

errno=9 is EBADF so maybe this is a dm issue after all?

BTW:

Maybe we will need to merge the following patch to log error messages 
from dm?

https://gitlab.com/MichalPrivoznik/libvirt/-/commit/ed3a7ae5d0cd3f492fe219dbd6b4820dde55841f

Michal