[pve-devel] [PATCH storage 0/2] fix #4997: lvm: avoid autoactivating (new) LVs after boot

[Friedrich Weber]

On 01/02/2024 09:26, Fiona Ebner wrote:
> Am 31.01.24 um 16:07 schrieb Friedrich Weber:
>> Thanks for the review!
>>
>> On 26/01/2024 12:14, Fiona Ebner wrote:
>>>> Some points to discuss:
>>>>
>>>> * Fabian and I discussed whether it may be better to pass `-K` and set the
>>>>   "activation skip" flag only for LVs on a *shared* LVM storage. But this may
>>>>   cause issues for users that incorrectly mark an LVM storage as shared, create a
>>>>   bunch of LVs (with "activation skip" flag), then unset the "shared" flag, and
>>>>   won't be able to activate LVs afterwards (`lvchange -ay` without `-K` on an LV
>>>>   with "activation skip" is a noop). What do you think?
>>>>
>>>
>>> Is there a way to prevent auto-activation on boot for LVs on a shared
>>> (PVE-managed) LVM storage? Also a breaking change, because users might
>>> have other LVs on the same storage, but would avoid the need for the
>>> flag. Not against the current approach, just wondering.
>>
>> One can also disable autoactivation for a whole VG (i.e., all LVs of
>> that VG):
>>
>> 	vgchange --setautoactivation n VG
>>
>> At least in my tests, after setting this no LV in that VG is active
>> after boot, so this might also solve the problem. I suppose setting this
>> automatically for existing VGs would be too dangerous (as users might
>> have other LVs in that VGs). But our LVM storage plugin *could* set this
>> when creating a new shared VG [1]?
>>
>> Not sure which option is better, though.
>>
> 
> Do you still need the -K flag to activate volumes in such a VG? If yes,
> nothing is gained compared to the more fine-grained "setting it on
> individual LVs". If no, we could save that. OTOH, users might want to
> use existing shared VGs and then they would need to apply this setting
> themselves.

Just looked into this again: No, if I set `--setautoactivation n` for a
VG, I don't need to pass -K to activate LVs within that VG. I think the
`--setautoactivation n` flag for VGs/LVs only affects autoactivation
(e.g. `vgchange -aay`, as done by udev, or `lvchange -aay`), not manual
activation (e.g. `vgchange -ay`/`lvchange -ay`).

> 
>>> Guardrails against issues caused by misconfiguration always warrant a
>>> cost-benefits analysis. What is the cost for also setting the flag for
>>> LVs on non-shared LVM storages? Or logic needs to be correct either way ;)
>>
>> AFAICT, setting this LV flag on non-shared LVM storages doesn't have
>> negative side-effects. I don't think we rely on autoactivation anywhere.
>> We'd need to take care of passing `-K` for all our `lvchange -ay` calls,
>> but AFAICT, `lvchange` calls are only done in the LVM/LvmThin plugins in
>> pve-storage.
>>
> 
> We need to have -K for activations, no matter if we only set the
> activationskip flag for shared or all. That's not an additional cost.