Bug 1230495

Summary: Created lvm devices are invisible to pvs or vgs and appears only after vgscan
Product: Red Hat Enterprise Linux 6 Reporter: Timothy Asir <tjeyasin>
Component: lvm2Assignee: Peter Rajnoha <prajnoha>
lvm2 sub component: Udev (RHEL6) QA Contact: cluster-qe <cluster-qe>
Status: CLOSED WONTFIX Docs Contact:
Severity: unspecified    
Priority: unspecified CC: agk, amulhern, dlehman, heinzm, jbrassow, msnitzer, prajnoha, prockai, tjeyasin, zkabelac
Version: 6.7   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-06 11:38:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1227742    

Description Timothy Asir 2015-06-11 04:10:23 UTC
Description of problem:
The lvm devices which are created using python-blivet becomes invisible to pvs or vgs and appears only after vgscan. This does not happens once we run vgscan
And also sometimes when we empty the disk device using dd command and create lvm out of it, we observed the created lvm devices became visible to vgs only after 1 or 2 minutes. This happens in a plain RHEL6 node it has only python-blivet installed.

Version-Release number of selected component (if applicable):
lvm2-2.02.118-2.el6.x86_64
lvm2-libs-2.02.118-2.el6.x86_64
python-blivet-1.0.0.1-1.el6rhs.noarch
Red Hat Enterprise Linux Server release 6.7 Beta (Santiago)

How reproducible:
Always till we run vgscan atleast one time

Actual results:
Create pv, vg, lv successfully. However it does not appear when we
run vgs or lvs or use python-blivet to list the devices

Comment 2 mulhern 2015-06-17 14:28:04 UTC
See bz#1227788 for more info, logs, etc.

Comment 3 Zdenek Kabelac 2015-08-24 11:42:23 UTC
I assume it could be related to the fact, that python API is rather not actively maintained and user should stay with executing  'real' lvm2 commands.

Python API should be only used as replacement for 'lvs'.

As a 'workaround' maybe you could try to disable usage of lvmetad and stop using this daemon (since the timing could be related to the fact devices are discovered later by udev)

Comment 4 mulhern 2015-08-24 11:52:45 UTC
Hi!

I'm not sure what Python API you are referring to.

In this context, python-blivet, which is actively maintained, is in the typical situation of executing lvm commands via a python subprocess call.

- mulhern

Comment 5 Zdenek Kabelac 2015-08-24 11:57:21 UTC
Ok - from the description  it seemed like it's describing problem from using  liblvm2app  and it's python binding from lvm2.

So in case  blivet calls real lvm2 commands - please provide full '-vvvv' of lvcreate command trace executed via Python Blivet API.

Then please show 'lvs' after such command (so we could see  LV is really missing)
and  'dmsetup table'  (so we could see it's really present & active).

Also attach your lvm.conf please.

Comment 6 mulhern 2015-08-24 13:32:03 UTC
Please see related bug, bz#1227788, which has the attachments requested.

Comment 7 Peter Rajnoha 2015-10-14 08:48:06 UTC
This looks like an issue with .cache file at first glance - we've done some fixes in this area already. For starters, is this reproducible with latest z-stream lvm2-2.02.118-3.el6_7.3 ?

Comment 8 Peter Rajnoha 2016-03-17 13:41:07 UTC
(In reply to Peter Rajnoha from comment #7)
> This looks like an issue with .cache file at first glance - we've done some
> fixes in this area already. For starters, is this reproducible with latest
> z-stream lvm2-2.02.118-3.el6_7.3 ?

Is this still reproducible with recent versions of lvm2?

Alternatively - is this reproducible when you have devices/obtain_device_list_from_udev=1 set in lvm.conf?

Comment 12 Jan Kurik 2017-12-06 11:38:32 UTC
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/

Comment 13 Red Hat Bugzilla 2023-09-14 03:00:29 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days