Bug 1377157
| Summary: | LVM cache not updating and reporting unknown device | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ribu Tho <rabraham> | |
| Component: | vdsm | Assignee: | Nir Soffer <nsoffer> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Natalie Gavrielov <ngavrilo> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | unspecified | CC: | alitke, amureini, bazulay, eedri, fdeutsch, gklein, gwatson, lsurette, mkalinin, nsoffer, pstehlik, rabraham, ratamir, srevivo, tnisan, ycui, ykaul, ylavi | |
| Target Milestone: | ovirt-4.1.1 | Keywords: | ZStream | |
| Target Release: | --- | Flags: | amureini:
needinfo+
|
|
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1429429 (view as bug list) | Environment: | ||
| Last Closed: | 2017-04-04 13:31:11 UTC | Type: | Bug | |
| 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: | 1374545 | |||
| Bug Blocks: | 1429429 | |||
|
Description
Ribu Tho
2016-09-19 01:40:38 UTC
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. |