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

[Fiona Ebner]

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.

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