Bug 1899214 - [RFE] add new LV flag to control autoactivation
Summary: [RFE] add new LV flag to control autoactivation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: lvm2
Version: 8.4
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: 8.0
Assignee: David Teigland
QA Contact: cluster-qe@redhat.com
Steven J. Levine
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-18 18:11 UTC by David Teigland
Modified: 2021-11-10 08:52 UTC (History)
13 users (show)

Fixed In Version: lvm2-2.03.12-1.el8
Doc Type: Enhancement
Doc Text:
.New LVM volume group flag to control autoactivation LVM volume groups now support a `setautoactivation` flag which controls whether logical volumes that you create from a volume group will be automatically activated on startup. When creating a volume group that will be managed by Pacemaker in a cluster, set this flag to `n` with the `vgcreate --setautoactivation n` command for the volume group to prevent possible data corruption. If you have an existing volume group used in a Pacemaker cluster, set the flag with `vgchange --setautoactivation n`.
Clone Of:
Environment:
Last Closed: 2021-11-09 19:45:20 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 5899741 0 None None None 2021-03-29 17:20:19 UTC
Red Hat Product Errata RHBA-2021:4431 0 None None None 2021-11-09 19:45:39 UTC

Description David Teigland 2020-11-18 18:11:39 UTC
Description of problem:

Create a new VG/LV flag to enable or disable autoactivation of LVs.  This would be similar to the existing "activationskip" flag, which applies to any activation command without -K.  The new flag would apply only to autoactivation commands (vgchange|lvchange|pvscan -aay).

The auto_activation_volume_list in lvm.conf could also be enhanced, but managing this in lvm.conf is more difficult than managing it in the VG metadata.

See this thread for one illustration of a case this would help:
https://www.redhat.com/archives/linux-lvm/2020-November/msg00003.html

lvcreate --autoactivation y|n
lvchange --autoactivation y|n

$ lvchange --autoactivation n LV

$ lvchange -aay LV
Error: autoactivation disabled for LV.

$ lvchange -ay LV
Activating LV.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 heming.zhao 2020-11-20 07:38:05 UTC
hello,

This problem mainly influnces vg+systemid in HA stack (corosync + pacemaker + Resource agent). The RA script LVM-activate needs to be enhanced.
lvchange with "-k" is not enough for LVM-activate when user only configs vg not specific lv.

Comment 3 Zdenek Kabelac 2021-03-30 08:07:26 UTC
I'd think the 'autoactivation' is rather property of VG -  it could be quite complicated if set per LV.

So to match  volume list in lvm.conf - the vgchange is likely the match here.

Comment 4 Zdenek Kabelac 2021-03-30 08:12:05 UTC
A side note is - if users want to prevent activation of individual LVs - users can already set  'lvchange --setactivationskip y vgname/lvname'.

Then such LV can be activated only with option -K   'lvchange -Kay vgname/lvname'.

Comment 5 David Teigland 2021-03-30 14:19:59 UTC
(In reply to Zdenek Kabelac from comment #3)
> I'd think the 'autoactivation' is rather property of VG -  it could be quite
> complicated if set per LV.

We already have activation skip per LV, so this is almost the same thing except for autoactivation.

Also, it has to be per LV because LVM-activate can be configured for individual LVs.

Comment 6 Zdenek Kabelac 2021-03-30 15:40:24 UTC
The point here for VG property should be - that once user opt-outs from autoactivation for a particular VG - he should have all newly created LV also not be autocatived.

The autoactivation itself has quite limited usage - happens only for the first time VG is discovered on the system - so seems all is tied to VG existence.

Creating then a new LVs would generally require to always also add a new option/lvchange to avoid  autoactivation for LV.
Doing that as LV  property heavily increase the complexity on user side - and I assume there will be more support case from mistakes in this handling
that actually a simple  switch at VG level.

If the  VG is set to be not autoactivated - the any newly created LV  also will be automatically deriving this property.


It's probably good to know who would be the user of this new option.
And what is the expected use-case.

My feeling is - users of this will always want to opt-out from autoactivation - and we are just helping the to avoid manipulation with lvm.conf

Per LV property requires IMHO a complex change on user's interface part as well to always handle proper setting per LV.

Comment 7 David Teigland 2021-03-30 15:54:59 UTC
Yes, good point, there should also be a matching VG flag that can be set to cover all LVs.  The flag can be set on individual LVs when there is not a single policy for the entire VG.

Comment 8 David Teigland 2021-04-01 22:45:18 UTC
An initial implementation can be found in this temp devel branch:
https://sourceware.org/git/?p=lvm2.git;a=commit;h=c195e7147dd6873d600b60fb029679083d4bebec

Comment 9 Zdenek Kabelac 2021-04-02 09:56:35 UTC
(In reply to David Teigland from comment #8)
> An initial implementation can be found in this temp devel branch:
> https://sourceware.org/git/?p=lvm2.git;a=commit;
> h=c195e7147dd6873d600b60fb029679083d4bebec

Here I'd suggest to always use compatible flags - so we do not break any compatibility with older lvm - the flag can be simply lost if operated on older system - instead of being unreadable.

Also for the consistency we should name this new option  --setautoactivationskip 
since  --autoactivation looks similar to -aay 
and it will also be better match for existing  --setactivationskip.

SPINDOWN define seems to be extra in patch.

Comment 10 David Teigland 2021-04-07 16:29:51 UTC
Thanks, the compatible flag is better, I kept --autoactivation y|n to avoid the problem of double/triple negatives in the usage.
https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/heads/dev-dct-autoactivation-setting

$ vgs -o+autoactivation bb
  VG #PV #LV #SN Attr   VSize   VFree   AutoAct
  bb   1   0   0 wz--n- 931.01g 931.01g enabled

$ lvcreate -l1 bb
  Logical volume "lvol0" created.

$ lvs -o+autoactivation bb
  LV    VG Attr       LSize AutoAct
  lvol0 bb -wi-a----- 4.00m enabled

$ lvchange -an bb

$ lvchange --autoactivation n bb/lvol0
  Logical volume bb/lvol0 changed.

$ lvs -o+autoactivation bb
  LV    VG Attr       LSize 
  lvol0 bb -wi------- 4.00m

$ lvchange -aay bb/lvol0

$ lvs bb
  LV    VG Attr       LSize 
  lvol0 bb -wi------- 4.00m

$ lvchange --autoactivation y bb/lvol0
  Logical volume bb/lvol0 changed.

$ lvchange -aay bb/lvol0

$ lvs bb
  LV    VG Attr       LSize 
  lvol0 bb -wi-a----- 4.00m

$ lvchange -an bb

$ vgchange --autoactivation n bb
  Volume group "bb" successfully changed

$ lvchange -aay bb/lvol0

$ lvs bb
  LV    VG Attr       LSize 
  lvol0 bb -wi------- 4.00m

Comment 11 David Teigland 2021-04-07 20:39:23 UTC
pushed to main:
https://sourceware.org/git/?p=lvm2.git;a=commit;h=0a28e3c44b05470061f15516e1c89a84fa2e8569

I changed the option name to --setautoactivation as suggested by Zdenek since the previous --autoactivation was fairly similar to --activate.

Comment 17 Corey Marthaler 2021-06-10 18:46:55 UTC
Feature verified on multiple volume segtypes using the latest rpms.

kernel-4.18.0-310.el8    BUILT: Thu May 27 14:24:00 CDT 2021
lvm2-2.03.12-2.el8    BUILT: Tue Jun  1 06:55:37 CDT 2021
lvm2-libs-2.03.12-2.el8    BUILT: Tue Jun  1 06:55:37 CDT 2021

# raid5
CHANGING SETAUTOACTIVATION (OFF) of raid5_6_9365/raid5_6_93650 on hayes-01
verifying setautoactivation is OFF on hayes-01
ls: cannot access '/dev/raid5_6_9365/raid5_6_93650': No such file or directory
CHANGING SETAUTOACTIVATION (ON) of raid5_6_9365/raid5_6_93650 on hayes-01
verifying setautoactivation is ON on hayes-01

# striped
deactivating VG stripe_2_1847 on hayes-02
CHANGING SETAUTOACTIVATION (OFF) of stripe_2_1847/stripe_2_18470 on hayes-02
verifying setautoactivation is OFF on hayes-02
ls: cannot access '/dev/stripe_2_1847/stripe_2_18470': No such file or directory
CHANGING SETAUTOACTIVATION (ON) of stripe_2_1847/stripe_2_18470 on hayes-02
verifying setautoactivation is ON on hayes-02

# linear
deactivating VG linear_5_1293 on hayes-03
CHANGING SETAUTOACTIVATION (OFF) of linear_5_1293/linear_5_12930 on hayes-03
verifying setautoactivation is OFF on hayes-03
ls: cannot access '/dev/linear_5_1293/linear_5_12930': No such file or directory
CHANGING SETAUTOACTIVATION (ON) of linear_5_1293/linear_5_12930 on hayes-03
verifying setautoactivation is ON on hayes-03

# raid10
deactivating VG raid10_2_7684 on hayes-02
CHANGING SETAUTOACTIVATION (OFF) of raid10_2_7684/raid10_2_76840 on hayes-02
verifying setautoactivation is OFF on hayes-02
ls: cannot access '/dev/raid10_2_7684/raid10_2_76840': No such file or directory
CHANGING SETAUTOACTIVATION (ON) of raid10_2_7684/raid10_2_76840 on hayes-02
verifying setautoactivation is ON on hayes-02

Comment 23 errata-xmlrpc 2021-11-09 19:45:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (lvm2 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4431


Note You need to log in before you can comment on or make changes to this bug.