-
Bug
-
Resolution: Done-Errata
-
Normal
-
None
-
rhel-9.4
-
lvm2-2.03.24-1.el9
-
None
-
Moderate
-
rhel-sst-logical-storage
-
ssg_filesystems_storage_and_HA
-
3
-
QE ack, Dev ack
-
False
-
-
None
-
None
-
None
What were you trying to do that didn't work?
During system boot, pvscan is run on LVs if a PV exists on it, in an attempt to autoactivate the layered VG. This goes against the default lvm behavior to ignore PVs on LVs. This occurs because blkid in an earlier udev rule scans the LV, identifies a PV on it, and causes 69-dm-lvm.rules to be run on it. The unwanted pvscan can easily be skipped in 69-dm-lvm.rules by recognizing the device as an LV. The current pvscan does not generally cause any harm, because the LV will be excluded by the pvscan for another reason, but log messages do appear from these unwanted pvscans. This problem will most often be seen when LVs are used to hold VM guest images, where the guest is using LVM, and the host sees the guest PV on the LV.
--- a/udev/69-dm-lvm.rules.in +++ b/udev/69-dm-lvm.rules.in @@ -10,6 +10,15 @@ SUBSYSTEM!="block", GOTO="lvm_end" ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", GOTO="lvm_end" +# Ignore PVs on LVs. +# This is usually a case of an LV being used for a guest VM +# image, where the guest is using lvm. The host should +# ignore lvm data from the guest and not attempt to scan or +# activate guest PVs/LVs. (To enable functions in this file +# for PVs layered on LVs, set LVM_PVSCAN_ON_LVS="1" from a +# custom udev rule.) +ENV{ID_FS_TYPE}=="LVM2_member", ENV{DM_UUID}=="LVM-?*", ENV{LVM_PVSCAN_ON_LVS}!="1", GOTO="lvm_end" +
Please provide the package NVR for which bug is seen:
How reproducible:
Steps to reproduce
Expected results
Actual results
- links to
-
RHBA-2024:136325 lvm2 bug fix and enhancement update