Bug 1429429 - [downstream clone - 4.0.7] LVM cache not updating and reporting unknown device
Summary: [downstream clone - 4.0.7] LVM cache not updating and reporting unknown device
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ovirt-4.0.7
: ---
Assignee: Nir Soffer
QA Contact: Kevin Alon Goldblatt
URL:
Whiteboard:
Depends On: 1377157
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-06 11:18 UTC by rhev-integ
Modified: 2019-12-16 07:35 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1377157
Environment:
Last Closed: 2017-03-07 11:45:35 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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


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