> Friedrich Weber <f.we...@proxmox.com> hat am 23.06.2025 11:25 CEST > geschrieben: > > > On 10/06/2025 17:00, Michael Köppl wrote: > > On 4/29/25 13:36, Friedrich Weber wrote: > >> When discovering a new volume group (VG), for example on boot, LVM > >> triggers autoactivation. With the default settings, this activates all > >> logical volumes (LVs) in the VG. Activating an LV creates a > >> device-mapper device and a block device under /dev/mapper. > >> > >> Autoactivation is problematic for shared LVM storages, see #4997 [1]. > >> For the inherently local LVM-thin storage it is less problematic, but > >> it still makes sense to avoid unnecessarily activating LVs and thus > >> making them visible on the host at boot. > >> > >> Hence, disable autoactivation after creating new LVs. As lvcreate > >> doesn't accept the --setautoactivation flag for thin LVs, this is done > >> with an additional lvchange command. With this setting, LVM > >> autoactivation will not activate these LVs, and the storage stack will > >> take care of activating/deactivating LVs when needed. > >> > >> [1] https://bugzilla.proxmox.com/show_bug.cgi?id=4997 > >> > >> Signed-off-by: Friedrich Weber <f.we...@proxmox.com> > >> --- > >> > >> Notes: > >> - would be great to get your opinion on whether we should consider > >> LVM-thin storages in this series or not. > >> > >> - passing --setautoactivation n to lvcreate for a thin volume says: > >> > >> Option --setautoactivation is unsupported with thins. > >> > >> But lvchange --setautoactivation seems to work on thin LVs, so the > >> fact that lvcreate doesn't accept it may be a bug. I reported it > >> upstream [1]. > >> > >> new in v3 > >> > >> [1] https://gitlab.com/lvmteam/lvm2/-/issues/32 > > > > Since the upstream issue has not been addressed yet and the change to > > LVM-thin does, AFAICT, not mitigate problems like in #4997 (or am I > > missing something here?), but is mostly done to streamline behavior, > > could the changes for LVM-thin be held back until it's clear that > > lvcreate not supporting --setautoactivation for LVM-thin is not on purpose? > > Good point. I agree disabling autoactivation isn't as important for > LVM-thin as it is for LVM-thick, though it's preferable also here that > VM disks are not always active on the host, but only activated on-demand > by our storage stack. > > From looking at the lvm2 commit introducing `--setautoactivation` [1] > the omission of --setautoactivation for thin LVs doesn't seem > intentional to me (maybe it was just forgotten to add to > LVCREATE_ARGS?), but I can't be 100% sure either. > > The problem with holding back the change for LVM-thin is that we also > need a way to update already-existing LVs, and the 8->9 bump is a good > opportunity to do so via pve8to9. > > @Fabian, what do you think?
it seems very likely this was by accident, and not by design. maybe opening an MR fixing it in addition to the issue gets more upstream attention? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
