On Wed, 09 Jul 2025 16:10:00 +0200, Friedrich Weber wrote:
> Starting with PVE 9, the LVM and LVM-thin plugins create new LVs with
> the `--setautoactivation n` flag to fix #4997 [1]. However, this does
> not affect already existing LVs of setups upgrading from PVE 8.
>
> Hence, add a new script under /usr/share/pve-manager/migrations that
> finds guest volume LVs with autoactivation enabled on enabled and
> active LVM and LVM-thin storages, and disables autoactivation for each
> of them. Before doing so, ask the user for confirmation for each
> storage. For non-interactive usecases, the user can pass an flag to
> assume confirmation. Disabling autoactivation via lvchange updates the
> LVM metadata, hence, the storage lock is acquired before proceeding.
> To avoid holding the lock for too long and blocking other consumers,
> the lvchange calls are batched and the lock is released between two
> batches. Afterwards, check for remaining guest volume LVs with
> autoactivation enabled (these may have been created while the lock was
> not held). If there are still such LVs left, or if other errors
> occurred, suggest the user to run the command again.
>
> [...]
Applied, thanks! As quickly talked off-list: I pushed a follow-up commit to
change the warning to a notice for the case where only local LVM storages are
affected, as in that case a warning is IMO not justified, as keeping the status
quo then has no known problems, and while it might be a bit cleaner and save a
little bit of resources to not activate all local volumes on boot, it's not
worth the relatively scary warning level.
[1/1] pve8to9: check for LVM autoactivation and provide migration script
commit: ebed71c822e25c03211cbf0f97a3ef0c25a3f86e
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
