From: David Teigland <teigland@redhat.com>
To: lvm-devel@redhat.com
Subject: dmeventd is not respecting /etc/lvm/devices/system.devices
Date: Fri, 29 Sep 2023 16:01:40 -0500 [thread overview]
Message-ID: <20230929210140.GA28125@redhat.com> (raw)
In-Reply-To: <fd47987d-5137-ee79-3e81-2c3228f2c9b3@ewheeler.net>
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,
or better just disable that service.
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.
Dave
next prev parent reply other threads:[~2023-09-29 21:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 19:18 dmeventd is not respecting /etc/lvm/devices/system.devices Eric Wheeler
2023-09-29 21:01 ` David Teigland [this message]
2023-09-30 0:47 ` Eric Wheeler
2023-09-30 13:53 ` Zdenek Kabelac
2023-09-30 14:03 ` Zdenek Kabelac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230929210140.GA28125@redhat.com \
--to=teigland@redhat.com \
--cc=lvm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.