Bug 1429429

Summary: [downstream clone - 4.0.7] LVM cache not updating and reporting unknown device
Product: Red Hat Enterprise Virtualization Manager Reporter: rhev-integ
Component: vdsmAssignee: Nir Soffer <nsoffer>
Status: CLOSED CURRENTRELEASE QA Contact: Kevin Alon Goldblatt <kgoldbla>
Severity: medium Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: alitke, amureini, bazulay, eedri, fdeutsch, gklein, gwatson, lsurette, mkalinin, nsoffer, pstehlik, rabraham, ratamir, srevivo, tnisan, ycui, ykaul, ylavi
Target Milestone: ovirt-4.0.7Keywords: TestOnly, ZStream
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: 1377157 Environment:
Last Closed: 2017-03-07 11:45:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1377157    
Bug Blocks:    

Description rhev-integ 2017-03-06 11:18:35 UTC 
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1377157 +++
======================================================================

Description of problem:

The Hypervisor reports errors with devices saying as unknown in pvs output commands with attribute in (m) state.

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

lvm2-2.02.130-5.el7_2.1.x86_64

How reproducible:


Steps to Reproduce:
1. Device is cached in LVM 
2. Being skipped during scans 
3. pvs reports as unknown device. 

Actual results:

device being reported as unknown though it contains the metadata and volume information on it that can be seen using hexdump . 

Expected results:

The output should contain the device with lvm header for the VG  in the output of the command. 

Additional info:

(Originally by Ribu Abraham)
Comment 4 rhev-integ 2017-03-06 11:19:00 UTC 
Tal, any idea from the storage side?

(Originally by Fabian Deutsch)
Comment 5 rhev-integ 2017-03-06 11:19:06 UTC 
Ribu, can you please provide the RHEV-H version used by the customer?

(Originally by Fabian Deutsch)
Comment 6 rhev-integ 2017-03-06 11:19:12 UTC 
Adam, Nir, any insights?

(Originally by Tal Nisan)
Comment 7 rhev-integ 2017-03-06 11:19:19 UTC 
Vdsm disable lvm autoback for most commands on RHEV lvs, so you cannot expect the
backups to reflect the state on storage.

Also, when running lvm commands on RHEL 7, you must disable lvmetad like this:

    lvs --config ' global { use_lvmetad = 0 }'

Or run this before the lvm command:

    pvscan --cache

I'm not sure that sos commands are doing this, so they may display incorrect 
results.

Ribu, can you check that the unexpected output happens when using lvm
commands properly?

(Originally by Nir Soffer)
Comment 12 rhev-integ 2017-03-06 11:19:52 UTC 
In 4.1 vdsm disabled lvmetad, so this issue should be eliminated. The current plan
is to backport it to 4.0.z.

(Originally by Nir Soffer)
Comment 13 rhev-integ 2017-03-06 11:20:00 UTC 
Needs to check this again, I don't think we understand the issue yet.

(Originally by Nir Soffer)
Comment 14 rhev-integ 2017-03-06 11:20:06 UTC 
(In reply to Nir Soffer from comment #12)
> Needs to check this again, I don't think we understand the issue yet.

I believe lvmetad disable was backported - anything else?

(Originally by Yaniv Kaul)
Comment 15 rhev-integ 2017-03-06 11:20:12 UTC 
Based on comment 11, I think we can safely mark this as modified since this looks
like another lvmetad issue.

(Originally by Nir Soffer)
Comment 18 Nir Soffer 2017-03-06 20:19:09 UTC 
Kevin, we don't know how to reproduce this issue. You can ask the reporter
for instructions, but I don't think it is possible to reproduce this.
Comment 19 Kevin Alon Goldblatt 2017-03-07 11:45:35 UTC 
Closed based on Comment 18