Bug 2214530

Summary: Include /etc/lvm/devices/system.devices in initramfs
Product: Red Hat Enterprise Virtualization Manager Reporter: Juan Orti <jortialc>
Component: vdsmAssignee: Nobody <nobody>
Status: CLOSED WONTFIX QA Contact: Lukas Svaty <lsvaty>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.5.3CC: aesteve, ahadas, lsurette, michal.skrivanek, srevivo, ycui
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-14 09:01:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Juan Orti 2023-06-13 09:25:29 UTC
Description of problem:
RHV configures the hypervisors to use LVM devices file to indicate which devices LVM should manage.

If the LVM devices file is not included in the initramfs, the host might fail to boot if a direct LUN mapped to the host but used by a VM has a VG with the same name as the one storing the root fs.

I request the file '/etc/lvm/devices/system.devices' to be always included in the initramfs if present. This is important for RHV, so we'll need a backport to RHEL 8.6 EUS.

Version-Release number of selected component (if applicable):
dracut-049-203.git20220511.el8_6.x86_64
kernel-4.18.0-372.57.1.el8_6.x86_64
RHEL 8.6 EUS

How reproducible:
Reproduced consistently in customer's environment, but it might depend on how the storage devices are enumerated.

Steps to Reproduce:
1. RHEL 8.6 EUS host configured as RHV hypervisor and using LVM devices:

   - Local disk sda3 used as PV in VG vg01
   - Root fs in vg01/rootlv
   - /etc/lvm/lvm.conf:
       devices {
         use_devicesfile = 1
       }

   - /etc/lvm/devices/system.devices:
       VERSION=1.1.1
       IDTYPE=sys_wwid IDNAME=naa.62cea7f06d5c1300292e704a17e40a3b DEVNAME=/dev/sda3 PVID=Uz2g4u8KLFW583MZZ66Gzn4i9rza1Y9f PART=3

2. The host has an additional LUN which is used by a VM. This LUN has a partition that contains a VG with the same name vg01

Actual results:
After a kernel upgrade and reboot, the boot process drops you to the dracut rescue shell. We see VG name conflicts like:

~~~
[  140.476866] dracut-initqueue[8221]: Scanning devices sda3 sdb sdc3 sde sdf sdg3 sdi  for LVM logical volumes vg01/rootlv
[  140.507358] dracut-initqueue[8246]: WARNING: VG name vg01 is used by VGs vHggYB-gnAO-Wyfl-4lUG-Ywrh-amtR-UC2bL5 and C0J65x-Ygmi-j2CG-Uykn-33Xx-drm6-mjqhfE.
[  140.514505] dracut-initqueue[8246]: inactive '/dev/vg01/rootlv' [100.00 GiB] inherit
[  140.542957] dracut-initqueue[8253]: WARNING: VG name vg01 is used by VGs vHggYB-gnAO-Wyfl-4lUG-Ywrh-amtR-UC2bL5 and C0J65x-Ygmi-j2CG-Uykn-33Xx-drm6-mjqhfE.
[  140.542957] dracut-initqueue[8253]: Fix duplicate VG names with vgrename uuid, a device filter, or system IDs.
~~~

Including /etc/lvm/devices/system.devices in the initramfs fixes the issue.

Expected results:
/etc/lvm/devices/system.devices should be always included in the initramfs.

Additional info:

Comment 1 Lukáš Nykrýn 2023-06-13 11:28:15 UTC
I don't think including this file is a way forward. We try not to include host-specific configuration files directly in the initrd. The main reason is that if such a configuration is changed, you must rebuild the initrd and there is no mechanism to enforce it. The preferred way is to add a new option specified on the kernel cmdline and parsed by the lvm dracut module.

Comment 2 Juan Orti 2023-06-13 12:23:21 UTC
(In reply to Lukáš Nykrýn from comment #1)
> I don't think including this file is a way forward. We try not to include
> host-specific configuration files directly in the initrd. The main reason is
> that if such a configuration is changed, you must rebuild the initrd and
> there is no mechanism to enforce it. The preferred way is to add a new
> option specified on the kernel cmdline and parsed by the lvm dracut module.

While I agree with what you say, it's also true that before using the LVM devices file RHV used an equivalent filter configuration that was stored in /etc/lvm/lvm.conf and included in the initramfs.

If you decide not to include the file by default, we can reassign this to the vdsm component to make it create a drop-in configuration file like described here: https://access.redhat.com/solutions/7018604

Comment 3 Lukáš Nykrýn 2023-06-13 13:48:02 UTC
(In reply to Juan Orti from comment #2)
> (In reply to Lukáš Nykrýn from comment #1)
> > I don't think including this file is a way forward. We try not to include
> > host-specific configuration files directly in the initrd. The main reason is
> > that if such a configuration is changed, you must rebuild the initrd and
> > there is no mechanism to enforce it. The preferred way is to add a new
> > option specified on the kernel cmdline and parsed by the lvm dracut module.
> 
> While I agree with what you say, it's also true that before using the LVM
> devices file RHV used an equivalent filter configuration that was stored in
> /etc/lvm/lvm.conf and included in the initramfs.
> 
> If you decide not to include the file by default, we can reassign this to
> the vdsm component to make it create a drop-in configuration file like
> described here: https://access.redhat.com/solutions/7018604

Yeah, I think that would be a better solution. In RHV you have better control over the system, and I think it is a bit safer to do it just there than in RHEL where users are doing weird stuff all the time.

Comment 5 Michal Skrivanek 2023-07-13 10:24:17 UTC
too large/risky change for a maintenance phase. Suggesting to close WONTFIX

Comment 6 Juan Orti 2023-07-13 11:12:00 UTC
This will only happen in case of a name conflict between the root VG and VGs in direct LUNs, so I expect that it'll be rare to hit the bug.

The solution is straightforward and documented in the KCS, so I'm ok with closing the bug.

Comment 7 Michal Skrivanek 2023-07-14 09:01:07 UTC
thanks, Juan. closing as per previous comment