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

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

On March 10, 2025 3:01 pm, Friedrich Weber wrote:
> On 07/03/2025 13:14, Fabian Grünbichler wrote:
>>> # LVM-thick/LVM-thin
>>>
>>> Note that this change affects all LVs on LVM-thick, not just ones on shared
>>> storage. As a result, also on single-node hosts, local guest disk LVs on
>>> LVM-thick will not be automatically active after boot anymore (after applying
>>> all patches of this series). Guest disk LVs on LVM-thin will still be
>>> auto-activated, but since LVM-thin storage is necessarily local, we don't run
>>> into #4997 here.
>> 
>> we could check the shared property, but I don't think having them not
>> auto-activated hurts as long as it is documented..
> 
> This is referring to LVs on *local* LVM-*thick* storage, right? In that
> case, I'd agree that not having them autoactivated either is okay
> (cleaner even).

yes

> The patch series currently doesn't touch the LvmThinPlugin at all, so
> all LVM-*thin* LVs will still be auto-activated at boot. We could also
> patch LvmThinPlugin to create new thin LVs with `--setautoactivation n`
> -- though it wouldn't give us much, except consistency with LVM-thick.

well, if you have many volumes not activating them automatically might
also save some time on boot ;) but yeah, shouldn't cause any issues.

>>> # Transition to LVs with `--setautoactivation n`
>>>
>>> Both v1 and v2 approaches only take effect for new LVs, so we should probably
>>> also have pve8to9 check for guest disks on (shared?) LVM that have
>>> autoactivation enabled, and suggest to the user to manually disable
>>> autoactivation on the LVs, or even the entire VG if it holds only PVE-managed
>>> LVs.
>> 
>> if we want to wait for PVE 9 anyway to start enabling (disabling? ;)) it, then
>> the upgrade script would be a nice place to tell users to fix up their volumes?
> 
> The upgrade script being pve8to9, right? I'm just not sure yet what to
> suggest: `lvchange --setautoactivation n` on each LV, or simply
> `vgchange --setautoactivation n` on the whole shared VG (provided it
> only contains PVE-managed LVs).

yes.

> 
>> OTOH, setting the flag automatically starting with PVE 9 also for existing
>> volumes should have no downsides, [...]
> 
> Hmm, but how would be do that automatically?

e.g., once on upgrading in postinst, or in activate_storage if we find a
cheap way to skip doing it over and over ;)

> 
>> we need to document anyway that the behaviour
>> there changed (so that people that rely on them becoming auto-activated on boot
>> can adapt whatever is relying on that).. or we could provide a script that does
>> it post-upgrade..
> 
> Yes, an extra script to run after the upgrade might be an option. Though
> we'd also need to decide whether to deactivate on each individual LV, or
> the complete VG (then we'd just assume that there no other
> non-PVE-managed LVs in the VG that the user wants autoactivated).

I think doing it on each volume managed by PVE is the safer and more
consistent option..

>>> We could implement something on top to make the transition smoother, some ideas:
>>>
>>> - When activating existing LVs, check the auto activation flag, and if auto
>>>   activation is still enabled, disable it.
>> 
>> the only question is whether we want to "pay" for that on each activate_volume?
> 
> Good question. It does seem a little extreme, also considering that once
> all existing LVs have autoactivation disabled, all new LVs will have the
> flag disabled as well and the check becomes obsolete.
> 
> It just occurred to me that we could also pass `--setautoactivation n`
> to `lvchange -ay` in `activate_volume`, but a test shows that this
> triggers a metadata update on *each activate_volume*, which sounds like
> a bad idea.

yeah that doesn't sound too good ;)


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel