Bug 672317
Summary: | LVs are unable to be deactivated when switching from local to cluster domain | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Corey Marthaler <cmarthal> |
Component: | lvm2 | Assignee: | David Teigland <teigland> |
lvm2 sub component: | Clustering / clvmd | QA Contact: | cluster-qe <cluster-qe> |
Status: | CLOSED WONTFIX | Docs Contact: | |
Severity: | medium | ||
Priority: | medium | CC: | agk, dwysocha, gianluca.cecchi, heinzm, jbrassow, joe.thornber, msnitzer, prajnoha, zkabelac |
Version: | 7.0 | Keywords: | Triaged |
Target Milestone: | pre-dev-freeze | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-11-09 21:13:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 756082 |
Description
Corey Marthaler
2011-01-24 19:54:14 UTC
So what should vgchange -cy do? Should it find the list of all locally-active LVs in that VG and activate them on other cluster nodes? What if some of them should be exclusively-activated locally? What about -cn? Should it deactivate them on remote nodes? My answers: vgchange -cy / -cn should not change the activation status of any LVs. vgchange -a should be used directly for that, so that local/exclusive changes can be dealt with explicitly. Instead, vgchange -cy should - behind the scenes - issue a 'lvchange -aly' for each already-active local LV, so that clvmd picks up the right state. (Some variation of --refresh might be another way.) -cn could fail if any LV is active on other nodes but leave a locally-active LV alone - but would clvmd know to drop the lock without deactivating the LV - could it tell from the no-longer-clustered metadata? Alterntively, there might be places in the clvmd code where it should re-check the 'clustered' state and modify its behaviour accordingly. This issue appears to occur only if the LV doesn't have a fixed minor number (the 'm' attr in the lvs output). If that attr does exist like volume stripe_4_4172/stripe_4_41720 below, this works fine. [root@grant-01 ~]# vgchange -cy stripe_4_4172 Volume group "stripe_4_4172" successfully changed [root@grant-01 ~]# vgs VG #PV #LV #SN Attr VSize VFree stripe_4_4172 4 2 0 wz--nc 476.80g 182.85g [root@grant-01 ~]# lvs LV VG Attr LSize lv stripe_4_4172 -wi-a- 100.00m stripe_4_41720 stripe_4_4172 -wima- 293.86g [root@grant-01 ~]# vgchange -an stripe_4_4172 1 logical volume(s) in volume group "stripe_4_4172" now active [root@grant-01 ~]# vgchange -an stripe_4_4172 1 logical volume(s) in volume group "stripe_4_4172" now active FWIW, the lvchange cmd makes no difference. [root@grant-02 ~]# lvs LV VG Attr LSize l_2_c linear_1_639 -wi-a- 100.00m [root@grant-02 ~]# lvchange -an linear_1_639/l_2_c [root@grant-02 ~]# lvs LV VG Attr LSize l_2_c linear_1_639 -wi-a- 100.00m *** Bug 684868 has been marked as a duplicate of this bug. *** Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. Two problems here seems... 1) what should happen with activated LVs after vgchange -cn 2) why LV with fixed minor number behaves differenly? Anyway, I think it still need upstream discussion how to handle 1) properly, until that happens cond nack/design. I stand by comment #2 and think the basic requirement/design is clear (but some implementation details remain to be worked out). vgchange -c should not activate or deactivate any LVs. Bug 672314 deals with restricting the use of -c to cases where no LVs need to change state anywhere in the cluster. This bug then deals with what's left, namely to ensure the clvmd lock state on the local node is updated to match reality after a -c transition. (Fixing that will hopefully be sufficient to make the various problems reported here go away - different parts of the code use different methods to find out whether or not an LV is active, and without this fix, could get inconsistent answers.) Let's simply disallow changing the cluster attribute unless all LVs are inactive, no? Let's not make this harder than it has to be. (In reply to Jonathan Earl Brassow from comment #16) > Let's simply disallow changing the cluster attribute unless all LVs are > inactive, no? Let's not make this harder than it has to be. This has already been fixed, no? Dave, would you mind checking it? 1. You can do vgchange -cy or -cn with locally active LVs. 2. You can't do vgchange -cn if there's a remotely active LV. 3. You can do vgchange -cy if there's a remotely active LV (only if system ID is not being used, which it should be.) The language of this message from point 2 makes it sound like point 1 is working as intended (whether that's a good idea or not): # vgchange -cn cc Can't change cluster attribute with active logical volume cc/lv1. Conversion is supported only for locally exclusive volumes. I suggest closing this as working well enough. RHEL8 uses new locking mechanism. If we haven't had customer issues with this so far, I'm fine WONTFIXing this bug. almost made it 10 years :( |