RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1676598 - Switch the default of "scanning LVs for LVM labels" from 'on' to 'off'
Summary: Switch the default of "scanning LVs for LVM labels" from 'on' to 'off'
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: lvm2
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: David Teigland
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On: 1674563
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-12 16:10 UTC by Jonathan Earl Brassow
Modified: 2021-09-07 11:53 UTC (History)
11 users (show)

Fixed In Version: lvm2-2.03.02-6.el8
Doc Type: Enhancement
Doc Text:
.New `scan_lvs` configuration setting A new `lvm.conf` configuration file setting, `scan_lvs`, has been added and set to 0 by default. The new default behavior stops LVM from looking for PVs that may exist on top of LVs; that is, it will not scan active LVs for more PVs. The default setting also prevents LVM from creating PVs on top of LVs. Layering PVs on top of LVs can occur by way of VM images placed on top of LVs, in which case it is not safe for the host to access the PVs. Avoiding this unsafe access is the primary reason for the new default behavior. Also, in environments with many active LVs, the amount of device scanning done by LVM can be significantly decreased. The previous behavior can be restored by changing this setting to 1.
Clone Of: 1674563
Environment:
Last Closed: 2019-06-13 22:52:52 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-12778 0 None None None 2021-09-07 11:53:23 UTC

Description Jonathan Earl Brassow 2019-02-12 16:10:02 UTC
+++ This bug was initially created as a clone of Bug #1674563 +++

It is a huge support issue that hypervisors are able to see the volume groups created within VMs.

The host machine will create logical volumes that then become the system disk for virtual machines.  Those virtual machines then create volume groups of their own on those disks.  Ideally, the host ignores them; but instead, the opposite is true.  The host scans its own LVs for labels and discovers the volume groups (and associated LVs) created by the VMs.

Support has been reporting problems where tools on the hypervisor are damaging VMs because they are writing to their (private LVs).  This can be avoided if we simply do not scan LVs for labels.

We can do this by switching the default setting in lvm.conf of:
  devices/scan_lvs = 1
to
  devices/scan_lvs = 0

--- Additional comment from Jonathan Earl Brassow on 2019-02-12 15:53:01 UTC ---

The noticeable, testable effect of this change will be that VGs that are created from a LV (or group of LVs) will no longer be visible or auto-activated.

Comment 2 Jonathan Earl Brassow 2019-02-12 16:13:25 UTC
I believe we can save our support organization a lot of headaches by making this change.  I've spoken with the GSS team and they agree that making this default change would save them a lot of calls and trouble.

We are in the process of changing this default value for the next RHEL7 minor release.  If we can't make this change in RHEL8.0, we would certainly do it in RHEL8.1.  It would be a shame if we could not start out RHEL8 with the defaults the way we have recently learned would provide the most benefit.

Comment 11 Corey Marthaler 2019-02-25 20:03:28 UTC
Marking verified in the latest rpms.

kernel-4.18.0-71.el8    BUILT: Fri Feb 22 17:00:18 CST 2019
lvm2-2.03.02-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
lvm2-libs-2.03.02-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-1.02.155-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-libs-1.02.155-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-event-1.02.155-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-event-libs-1.02.155-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-persistent-data-0.7.6-1.el8    BUILT: Sun Aug 12 04:21:55 CDT 2018



# LV PV create attempt                                                                                                                                                                                                                        
[root@hayes-02 lvm]# pvcreate -y --config devices/scan_lvs=0 /dev/snapper_thinp/snap_level1                                                                                                                                                     
  Device /dev/snapper_thinp/snap_level1 excluded by a filter.                                                                                                                                                                                   
[root@hayes-02 lvm]# pvcreate -y --config devices/scan_lvs=1 /dev/snapper_thinp/snap_level1                                                                                                                                                     
  Physical volume "/dev/snapper_thinp/snap_level1" successfully created.                                                                                                                                                                         
                                                                                                                                                                                                                                                 
# LV VG create attempt                                                                                                                                                                                                                           
[root@hayes-02 lvm]# vgcreate STACK /dev/snapper_thinp/snap_level1                                                                                                                                                                                
  Device /dev/snapper_thinp/snap_level1 excluded by a filter.                                                                                                                                                                                     
[root@hayes-02 lvm]# vgcreate STACK --config devices/scan_lvs=1 /dev/snapper_thinp/snap_level1                                                                                                                                                     
  Volume group "STACK" successfully created

# LV stacked on LV create attempt
[root@hayes-02 lvm]# lvcreate -L 100m STACK
  Volume group "STACK" not found
  Cannot process volume group STACK
[root@hayes-02 lvm]# lvcreate --config devices/scan_lvs=1 -L 100m STACK
  Logical volume "lvol0" created.

# lvs display
[root@hayes-02 lvm]# lvs -a -o +devices
  LV              VG            Attr       LSize Pool Origin Data%  Meta%  Devices
  POOL            snapper_thinp twi-aotz-- 1.00g             0.02   11.62  POOL_tdata(0)
  [POOL_tdata]    snapper_thinp Twi-ao---- 1.00g                           /dev/sdl1(1)
  [POOL_tmeta]    snapper_thinp ewi-ao---- 4.00m                           /dev/sdn1(0)
  [lvol0_pmspare] snapper_thinp ewi------- 4.00m                           /dev/sdl1(0)
  origin          snapper_thinp Vwi-a-tz-- 1.00g POOL        0.00
  snap_level1     snapper_thinp Vwi-aotz-- 1.00g POOL origin 0.02
[root@hayes-02 lvm]# lvs --config devices/scan_lvs=1 -a -o +devices
  LV              VG            Attr       LSize   Pool Origin Data%  Meta%  Devices
  lvol0           STACK         -wi-a----- 100.00m                           /dev/snapper_thinp/snap_level1(0)
  POOL            snapper_thinp twi-aotz--   1.00g             0.02   11.62  POOL_tdata(0)
  [POOL_tdata]    snapper_thinp Twi-ao----   1.00g                           /dev/sdl1(1)
  [POOL_tmeta]    snapper_thinp ewi-ao----   4.00m                           /dev/sdn1(0)
  [lvol0_pmspare] snapper_thinp ewi-------   4.00m                           /dev/sdl1(0)
  origin          snapper_thinp Vwi-a-tz--   1.00g POOL        0.00
  snap_level1     snapper_thinp Vwi-aotz--   1.00g POOL origin 0.02

# vgs display
[root@hayes-02 lvm]# vgs
  VG            #PV #LV #SN Attr   VSize VFree 
  snapper_thinp   5   8   0 wz--n- 2.18t <2.18t
[root@hayes-02 lvm]# vgs --config devices/scan_lvs=1
  VG            #PV #LV #SN Attr   VSize    VFree  
  STACK           1   1   0 wz--n- 1020.00m 920.00m
  snapper_thinp   5   8   0 wz--n-    2.18t  <2.18t


Note You need to log in before you can comment on or make changes to this bug.