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

Fiona Ebner f.ebner at proxmox.com
Thu Feb 1 09:26:33 CET 2024

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

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

More information about the pve-devel mailing list