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:
Tal, any idea from the storage side?
Ribu, can you please provide the RHEV-H version used by the customer?
Adam, Nir, any insights?
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?
In 4.1 vdsm disabled lvmetad, so this issue should be eliminated. The current plan is to backport it to 4.0.z.
Needs to check this again, I don't think we understand the issue yet.
(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?
Based on comment 11, I think we can safely mark this as modified since this looks like another lvmetad issue.
No patches attached to the bug, there is not way for the bot to know if this was fixed in a certain build. Please add the relevant patches with the fix.
(In reply to Eyal Edri from comment #17) > No patches attached to the bug, there is not way for the bot to know if this > was fixed in a certain build. > Please add the relevant patches with the fix. This bug should be fixed by the changes in bug 1374545, this is why we marked it as modified.
(In reply to Nir Soffer from comment #18) > (In reply to Eyal Edri from comment #17) > > No patches attached to the bug, there is not way for the bot to know if this > > was fixed in a certain build. > > Please add the relevant patches with the fix. > > This bug should be fixed by the changes in bug 1374545, this is why we > marked it > as modified. And moved to ON_QA alognside it.
I don't really get the scenario described in comment 0 (in "steps to reproduce" it seems that steps 2 and 3 are more a result rather than steps) Any suggestions on how to test this fix here, a concrete scenario?
(In reply to Natalie Gavrielov from comment #23) > I don't really get the scenario described in comment 0 (in "steps to > reproduce" it seems that steps 2 and 3 are more a result rather than steps) > Any suggestions on how to test this fix here, a concrete scenario? I don't think it is possible to test such issue. We disabled lvmetad so lvm cache cannot be incorrect now, since we don't have any.