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

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.