Re: dmeventd is not respecting /etc/lvm/devices/system.devices

On Fri, 29 Sep 2023, David Teigland wrote:
> On Fri, Sep 29, 2023 at 12:18:07PM -0700, Eric Wheeler wrote:
> > Hello all,
> > 
> > I am not sure how to resolve the dmeventd warning below, maybe you can 
> > help. It appears that dmeventd is finding PVs attached to VMs, but those 
> > volumes are not listed in /etc/lvm/devices/system.devices so, presumably, 
> > they should be ignored by dmeventd.
> 
> Thanks for bringing his up, it's a neglected and hidden corner of the
> devices file feature that's not well developed.
> 
> The existing solution to this problem isn't great, but should work: create
> /etc/lvm/devices/dmeventd.devices, where dmeventd.devices contains devs
> for any VG where dmeventd is needed.  That might be the same as
> system.devices (you could just copy system.devices to dmeventd.devices.)
> If you don't actually need dmeventd, then dmeventd.devices could be empty,

For now we created an empty dmeventd.devices file which seems to do what 
we need.

> or better just disable that service.

What is the proper way to disable dm-event?  I tried systemctl but it 
barks:

	# systemctl disable dm-event
	The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
	Alias= settings in the [Install] section, and DefaultInstance= for template
	units). This means they are not meant to be enabled or disabled using systemctl.
	 
	Possible reasons for having this kind of units are:
	• A unit may be statically enabled by being symlinked from another unit's
	  .wants/ or .requires/ directory.
	• A unit's purpose may be to act as a helper for some other unit which has
	  a requirement dependency on it.
	• A unit may be started when needed via activation (socket, path, timer,
	  D-Bus, udev, scripted systemctl call, ...).
	• In case of template units, the unit is meant to be enabled with some
	  instance name specified.

> Without a dmeventd.devices file, dmeventd does not use any devices file
> and looks at all PVs on the system, as you've seen.  This was a quick way
> get around the fact that multiple devices files can be used, but dmeventd
> needs to service all of them.  It turns out multiple devices files aren't
> really used by anyone, as far as I can tell (at least not yet.)  The
> default should be for dmeventd to use system.devices, I expect we can make
> that change for the next release.
> 
> > We used to use `global_filter` and that worked fine, but that seems to be 
> > deprecated starting in el9 in favor of system.devices. If we try to enable 
> > the filters in lvm.conf, then pvs/lvs/vgs commands complain about the 
> > filter options being used together with `use_devicesfile=1`. Note that we 
> > have PVs on LVs for ssd allocation to different VGs, so `scan_lvs=1` is 
> > enabled.  (Maybe turning off scan_lvs would "fix" dmeventd, but I can't 
> > test that because we need PVs on LVs for this deployment.)
> 
> I don't think scan_lvs will have any impact on this.
> 
> > Aug 28 15:25:29 hv1.ewheeler.net dmeventd[886522]: WARNING: VG name data is used by VGs pcqIki-TjE0-iFMN-D8MH-19Er-ypSm-djfl5D and 9UEiuo-DYzj-UTLi-XYCi-KiBO-wQi2-w5QUtX.
> 
> It's always been difficult to know what dmeventd is doing, and I wonder
> what it's running so frequently.

Thats funny, me too. Your answer definitely sheds some light on the 
situation.  Thanks for the quick response.

-Eric

> 
> Dave
> 
>

--
lvm-devel mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/lvm-devel