Bug 891271
| Summary: | A running LVM process can't switch over between lvmetad and non-lvmetad mode | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Nenad Peric <nperic> |
| Component: | lvm2 | Assignee: | LVM and device-mapper development team <lvm-team> |
| lvm2 sub component: | LVM Metadata / lvmetad | QA Contact: | cluster-qe <cluster-qe> |
| Status: | CLOSED WONTFIX | Docs Contact: | |
| Severity: | low | ||
| Priority: | low | CC: | agk, dwysocha, heinzm, jbrassow, msnitzer, prajnoha, thornber, zkabelac |
| Version: | 7.3 | Keywords: | Triaged |
| 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: | 2019-08-06 01:36:30 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: | |||
But of more concern is why lvmetad died - it shouldn't be dying! Can you link this to a bug covering that with core dump etc? As lvmetad should never be dying during an operation like this, this bugzilla is low priority. I think it's better to stop rather than fall back, but there should be an error message explaining there was a problem communicating with lvmetad instead of the 'not found' message. Seems I inadvertently introduced some confusion, sorry. I forgot to clarify that this actually comes as an 'offspring' of a different bug. It is actually from Bug 823918, since Petr Rockai said this is not the same issue as described in that bug (segfaulting) and a new bug should be opened. I forgot to write that when I opened this bug, but I added it as targeted for 6.5 since it is low priority currently. To clarify it: If for some reason lvmetad dies during an ongoing LVM operation (lets say someone stops it or it just crashes for some reason), the process can't switch over between lvmetad and non-lvmetad mode of operation on the fly. 1) lvmetad should never die while lvm is running: the whole reason it exists demands that it has to be ultra-reliable. Any failure in lvmetad is serious and must be fixed urgently. lvmetad must be more reliable than the lvm client calling it. 2) In the event that it does die, it's OK for the client to inform the user of this and then stop. As this shouldn't ever happen, I don't think it's necessary at this stage to attempt to write some 'fallback' code that switches transparently to non-lvmetad operation. Well, neither is quite entirely true. First, lvmetad is designed in such a way that its failure is in no way critical. In particular, it is safe to restart, which as far as clients are concerned is no different from a crash. Moreover, we have long-running processes that connect to lvmetad: pvmove and lvconvert have been mentioned. This is not critical either, but it'd be nice if polldaemon could survive a lvmetad restart. On the other hand, nothing *really* bad is going to happen if polldaemon dies, it just needs to be started again. In future, when LVM internals are better organized, it shouldn't be very hard to cleanly "fail over" from lvmetad to scanning even mid-command. Of course, we can keep trying to reconnect before every scan, which is, I think, a good compromise. No plans to fix this in rhel7 and lvmetad is not present in rhel8 |
Description of problem: If LVM is running with lvmetad, and doing a long-lasting process (lvconvert or worse pvmove) it does not know how to cope with a failing lvmetad. lvconvert concretely returns to command prompt saying that there is no vg on which to work on. How reproducible: Everytime Steps to Reproduce: pvcreate /dev/sd{a..e}1 vgcreate vg /dev/sd{a..e}1 lvcreate vg -n lv -L 10G lvconvert -m1 --alloc anywhere --corelog vg/lv Actual results: (05:34:06) [root@r6-node01:~]$ pvcreate /dev/sd{a..e}1 Physical volume "/dev/sda1" successfully created Physical volume "/dev/sdb1" successfully created Physical volume "/dev/sdc1" successfully created Physical volume "/dev/sdd1" successfully created Physical volume "/dev/sde1" successfully created (05:34:16) [root@r6-node01:~]$ vgcreate vg /dev/sd{a..e}1 Volume group "vg" successfully created (05:34:35) [root@r6-node01:~]$ lvcreate vg -n lv -L 10G Logical volume "lv" created (05:35:12) [root@r6-node01:~]$ lvconvert -m1 --alloc anywhere --corelog vg/lv vg/lv: Converted: 0.0% vg/lv: Converted: 3.9% vg/lv: Converted: 7.0% vg/lv: Converted: 10.0% Volume group "vg" not found Expected results: Add a capability to silently fail-over to non-lvmetad functionality (maybe with a warning that lvmetad is not accessible and that fall back is in place), and not misleading the user by stating that his VG is somehow "lost" Or - just not to return to the prompt with an error and finish what it was doing. - have a message that lvmetad has died and inform the user what has happened/is hapenning (in the case of lvconvert, that the converting is still being done in the background).