Bug 1899214

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.

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.

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'.

(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.

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.

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.

An initial implementation can be found in this temp devel branch:
https://sourceware.org/git/?p=lvm2.git;a=commit;h=c195e7147dd6873d600b60fb029679083d4bebec

(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.

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

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.

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

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