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

[Christian Ehrhardt]

On Tue, Aug 18, 2020 at 12:47 PM Christian Ehrhardt
<christian.ehrhardt at canonical.com> wrote:
>
> On Tue, Aug 18, 2020 at 12:11 PM Christian Ehrhardt
> <christian.ehrhardt at canonical.com> wrote:
> >
> > On Tue, Aug 18, 2020 at 11:36 AM Michal Privoznik <mprivozn at redhat.com> wrote:
> > >
> > > v2 of:
> > >
> > > https://www.redhat.com/archives/libvir-list/2020-August/msg00489.html
> > >
> > > diff to v1:
> > > - After discussion to v1 I've decided to not cache DM major number and
> > >   thus the patches looks a bit different.
> > >
> > > Michal Prívozník (2):
> > >   virdevmapper: Don't cache device-mapper major
> > >   virdevmapper: Handle kernel without device-mapper support
> >

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?