Re: [PATCH v2 0/2] Deal with kernels without DM support

On Tue, Aug 18, 2020 at 12:47 PM Christian Ehrhardt <christian.ehrhardt(a)canonical.com&gt; wrote: I put this through further testing and while working on containers in general now, I found it breaks if I expose (an unusable) /dev/mapper/control to the guest. The guest isn't able to access it properly, but it exists and that breaks libvirt 6.6 even with the recent virdevmapper fixes applied. Conditions: It is available: # grep mapper /proc/devices 253 device-mapper # ll /dev/mapper/control crw------- 1 root root 10, 236 Aug 19 08:36 /dev/mapper/control But not usable: # dmsetup table /dev/mapper/control: open failed: Operation not permitted Failure to communicate with kernel device-mapper driver. Check that device-mapper is available in the kernel. Incompatible libdevmapper 1.02.167 (2019-11-30) and kernel driver (unknown version). Command failed. I could further unconfine it to eventually work, but what I'd want for now is that as discusse don IRC we might consider more bad RCs as "devmapper not in use, don't remap paths" For reference `dmsetup table` also gets: 0.000082 stat("/dev/mapper/control", {st_mode=S_IFCHR|0600, st_rdev=makedev(0xa, 0xec), ...}) = 0 <0.000021> 0.000094 openat(AT_FDCWD, "/dev/mapper/control", O_RDWR) = -1 EPERM (Operation not permitted) <0.000021> Starting the guest fails similar like it did in former issues around this: # virsh start kvm-testguest-groovy-1 error: Failed to start domain kvm-testguest-groovy-1 error: internal error: Process exited prior to exec: libvirt: QEMU Driver error : Unable to get devmapper targets for /var/lib/uvtool/libvirt/images/kvm-testguest-groovy-1.qcow: Operation not permitted The strace of libvirt itself looks like: # grep -C 3 -e 'mapper\/control' libvirt.strace.* libvirt.strace.5332- 0.000066 lstat("/dev/ptmx", {st_mode=S_IFCHR|0666, st_rdev=makedev(0x5, 0x2), ...}) = 0 <0.000014> libvirt.strace.5332- 0.000079 lstat("/dev/kvm", {st_mode=S_IFCHR|0660, st_rdev=makedev(0xa, 0xe8), ...}) = 0 <0.000014> libvirt.strace.5332- 0.000072 lstat("/var/lib/uvtool/libvirt/images/kvm-testguest-groovy-1.qcow", {st_mode=S_IFREG|0600, st_size=229638144, ...}) = 0 <0.000018> libvirt.strace.5332: 0.000067 openat(AT_FDCWD, "/dev/mapper/control", O_RDWR) = -1 EPERM (Operation not permitted) <0.000017> libvirt.strace.5332- 0.000142 umount2("/run/libvirt/qemu/5-kvm-testguest-groovy.dev", 0) = 0 <0.000195> libvirt.strace.5332- 0.000254 stat("/run/libvirt/qemu/5-kvm-testguest-groovy.dev", {st_mode=S_IFDIR|0775, st_size=40, ...}) = 0 <0.000016> libvirt.strace.5332- 0.000068 access("/run/libvirt/qemu/5-kvm-testguest-groovy.dev", F_OK) = 0 <0.000015> And according to our IRC discussion: [10:33] <mprivozn> on the other hand, it might not be that dirty, if we can't open /dev/mapper/control for whatever reason then we can safely assume that devmapper is not available/able to answer our queries and thus no mpath devices can be on the system anyway [10:33] <cpaelzer_> true [10:33] <danpb> mprivozn: the only problem is that EPERM just indicates libvirtd can't access it [10:33] <mprivozn> cpaelzer_: either will show what the problem is; my guess is that open(/dev/mapper/control) in virDMOpen() fails [10:34] <danpb> mprivozn: doesn't mean it can't be in use [10:36] <mprivozn> danpb: agreed; but if we can't get deps for mpath (or determine that its mpath) then I'd say move on with domain startup and hope it wasn't mpath (which is a very narrow use case anyway) [10:36] <danpb> yeah probably best on balance So EPERM it is, would you add a change ignoring that RC please?