RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 891271 - A running LVM process can't switch over between lvmetad and non-lvmetad mode
Summary: A running LVM process can't switch over between lvmetad and non-lvmetad mode
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.3
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-02 12:07 UTC by Nenad Peric
Modified: 2023-03-08 07:25 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-06 01:36:30 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Nenad Peric 2013-01-02 12:07:57 UTC 
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).
Comment 2 Alasdair Kergon 2013-01-02 12:35:32 UTC 
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?
Comment 3 Alasdair Kergon 2013-01-02 12:38:28 UTC 
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.
Comment 4 Nenad Peric 2013-01-02 15:38:33 UTC 
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.
Comment 6 Alasdair Kergon 2013-10-08 13:35:56 UTC 
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.
Comment 7 Petr Rockai 2013-10-09 11:00:11 UTC 
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.
Comment 12 Jonathan Earl Brassow 2019-08-06 01:36:30 UTC 
No plans to fix this in rhel7 and lvmetad is not present in rhel8
Note You need to log in before you can comment on or make changes to this bug.