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 1387819 - vg suddenly goes missing for a pv
Summary: vg suddenly goes missing for a pv
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.8
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-22 05:29 UTC by nikhil kshirsagar
Modified: 2020-03-11 15:19 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-23 23:09:02 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
lvm debug logs showing a normal pvs output followed by the problem seen (113.46 KB, text/plain)
2016-10-22 05:33 UTC, nikhil kshirsagar 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2859661 0 None None None 2017-01-16 05:49:12 UTC

Comment 2 nikhil kshirsagar 2016-10-22 05:33:46 UTC 
Created attachment 1212992 [details]
lvm debug logs showing a normal pvs output followed by the problem seen
Comment 6 Zdenek Kabelac 2016-10-25 08:30:00 UTC 
Can we see the content of  1MB of /dev/vdb ?


cache/lvmcache.c:1513   lvmcache: /dev/vdb: now in VG #orphans_lvm2 (#orphans_lvm2) with 0 mdas
format_text/text_label.c:422   /dev/vdb: PV header extension version 1 found
format_text/format-text.c:1176   /dev/vdb: found metadata with offset 0.
device/dev-io.c:614   Closed /dev/vdb
device/dev-io.c:559   Opened /dev/vdc RO O_DIRECT

Doesn't look correct.

Is there ANYONE else updating  metadata in parallel without locking ?

Is disk shared with someone else ?

i.e.  host and guest  both see the device ?
Comment 9 Zdenek Kabelac 2016-10-25 10:01:27 UTC 
Yep 

'before'  has  seqno  22

and PV  V83deV-l32G-dZ1u-viO3-PeL3-Chmz-q290Fh
was located on /dev/vdc with   479 extents


'after'  has 2 more seqno 23 & 24:

version 23  for UUID V83deV-l32G-dZ1u-viO3-PeL3-Chmz-q290Fh
is now on  /dev/vdb with 959 extents

as well as  version 24

and likely there was unprotected access - 
so pointer to metadata sector has been cleared along the way.

So is the user trying to do some  LIVE resize on Host machine with some 'vision' of having new space available in Guest ?

(surely this will not work this way)
Comment 11 Germano Veit Michel 2016-12-29 23:38:34 UTC 
Adding LVM filters on the Host makes the problem go away. The filters are the same as we proposed on BZ #1374545.

Zdenek, do you think this could be some other effect of that BZ, but on RHEL6 - this time LVs are not activated, but the Host is "seeing them", what apparently triggers this behavior. When they are hidden, the problem goes away.
Comment 12 Zdenek Kabelac 2017-01-02 15:24:16 UTC 
Setting correct filter and  avoiding parallel UNPROTECTED access to lvm2 metadata is mandatory condition for proper lvm2 usage.

lvm2 simply can't work reliable when different commands are changing SAME disk space at the same time.  This is responsibility of system administrator to properly configure the system for this.
Comment 13 Germano Veit Michel 2017-01-09 04:38:19 UTC 
Thanks Zdenek, opened BZ #1411197 to track this from RHV side.
Comment 15 Germano Veit Michel 2017-03-23 23:09:02 UTC 
This turned out to be a RHV problem. With proper LVM filtering in the Hypervisor this doesn't happen.

There are several BZs in RHV handling this, I don't think there is anything to be done on RHEL or lvm, therefore closing the bug.
Note You need to log in before you can comment on or make changes to this bug.