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.
BTW, I ran the same tests on kernel 4.12 and kernel 5.6, Got the same
test results.
Thanks,
Lin