Bug 1727270 - pvscan[192] PV /dev/sda ignore for size 204800 not matching device 2097152 breaks virt-resize
Summary: pvscan[192] PV /dev/sda ignore for size 204800 not matching device 2097152 br...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: lvm2
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.1
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs 1723275
TreeView+ depends on / blocked
 
Reported: 2019-07-05 10:11 UTC by Richard W.M. Jones
Modified: 2019-11-05 22:35 UTC (History)
11 users (show)

Fixed In Version: lvm2-2.03.05-2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 22:35:15 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:3654 None None None 2019-11-05 22:35:53 UTC

Description Richard W.M. Jones 2019-07-05 10:11:06 UTC
Description of problem:

See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1723275#c6

LVM2 has added a new check in pvscan:

  pvscan[192] PV /dev/sda ignore for size 204800 not matching device 2097152.

This breaks virt-resize which resizes the underlying disk
before calling pvresize to resize the device.

Please remove this check, it's wrong.

Version-Release number of selected component (if applicable):

lvm2 2.03.05-1.el8

How reproducible:

100%

Steps to Reproduce:

There is a reproducer here:
https://bugzilla.redhat.com/show_bug.cgi?id=1723275#c6

Comment 1 Richard W.M. Jones 2019-07-05 10:11:39 UTC
Upstream commit was:

commit 7836e7aa1c17216ed368fda89cfc805a07efda81
Author: David Teigland <teigland@redhat.com>
Date:   Fri Apr 5 16:44:00 2019 -0500

    pvscan: ignore device with incorrect size
    
    If a device looks like a PV, but its size does not
    match the PV size in the metadata, then skip it for
    purposes of autoactivation.  It's probably not wrong
    device for the PV.

Comment 2 David Teigland 2019-07-08 16:24:37 UTC
I understand that we allow the device to be larger than the PV (for the obvious case of pvresize), but I did not believe that autoactivation needed to worry about this case.  I guess you have found a case where autoactivation does need to worry about it.  The check was another attempt to exclude md component devices with superblocks at the end of the devices, but I'll have to rework that check.

Comment 3 David Teigland 2019-07-08 17:49:36 UTC
Incidentally, even with this fixed, cases like this are probably better off using direct activation instead of event based activation (set event_activation=0 in lvm.conf).

Comment 4 Zdenek Kabelac 2019-07-09 09:18:27 UTC
PV size may not match size of device at any time - it's not related to autoactivation.

User can set explicitly the size of used portion of device with  'pvcreate --setphysicalvolumesize'.

So if we have put any filtering rule based on PV matching device size - this limitation needs to be restored back.

i.e. user can resize up/down partition table anytime later on - lvm2 only uses the size specified in PV header.

Comment 5 Igor Mammedov 2019-07-11 14:31:12 UTC
My workstation fails to boot since filesystems from fstab can not be found due to not activated volumes,
which used to work before (so restriction in current form causing regression).
It drops into maintenance mode and can be booted only after explicit 'vgchange -a y'.

(users probably wouldn't be very happy after update)

Comment 6 David Teigland 2019-07-11 17:00:45 UTC
These two commits fix the problem:

https://sourceware.org/git/?p=lvm2.git;a=commit;h=f17353e3e604ad2d80bcd77ea0a6a93472e6b5bd

md component detection for differing PV and device sizes

This check was mistakenly removed when shifting code in commit
"separate code for setting devices from metadata parsing".

Put it back with some new conditions.


https://sourceware.org/git/?p=lvm2.git;a=commit;h=b16abb3816408a296343a75658d4be0ef688390b

pvscan: fix PV online when device has a different size

Fix commit 7836e7aa1c17216ed368fda89cfc805a07efda81
"pvscan: ignore device with incorrect size"

which caused pvscan to not consider a PV online (for purposes
of event based activation) if the PV and device sizes differed.

This helped to avoid mistaking MD components for PVs, and is
replaced by triggering an md component check when PV and device
sizes differ (which happens in set_pv_device).

Comment 7 Marian Csontos 2019-07-12 09:00:36 UTC
How to reproduce this? QE will need a better reproducer than using virt-resize IMO.

I have a VM with PVs which do not match the size of underlying device and it boots fine and the LV is activated. I tried both PV on /dev/sda and with a partitioned device.

What am I missing?

Comment 8 Richard W.M. Jones 2019-07-12 09:28:00 UTC
There is a reproducer in:

https://bugzilla.redhat.com/show_bug.cgi?id=1723275#c6

which does not involve running virt-resize.

Comment 9 David Teigland 2019-07-12 15:29:03 UTC
Along with the fixes I pushed a test that fails without the fixes:
https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=7230aa891c4186ab425f6821c25101d9049fadde

Comment 11 Roman Bednář 2019-07-23 11:12:07 UTC
Thank you for simplified reproducer (Comment 8). Adding QA ack for 8.1

Comment 13 Roman Bednář 2019-08-14 12:38:08 UTC
Verified with latest rpms.

# guestfish --ro -a test1.img run : debug ll /dev/mapper
total 0
drwxr-xr-x  2 root root     120 Aug 14 12:36 .
drwxr-xr-x 17 root root    2640 Aug 14 12:36 ..
lrwxrwxrwx  1 root root       7 Aug 14 12:36 VG-boot -> ../dm-0
lrwxrwxrwx  1 root root       7 Aug 14 12:36 VG-root -> ../dm-2
lrwxrwxrwx  1 root root       7 Aug 14 12:36 VG-swap -> ../dm-1
crw-------  1 root root 10, 236 Aug 14 12:36 control


lvm2-2.03.05-2.el8.x86_64

Comment 15 errata-xmlrpc 2019-11-05 22:35:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3654


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