On 01/02/2024 09:26, Fiona Ebner wrote: > 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.
Just looked into this again: No, if I set `--setautoactivation n` for a VG, I don't need to pass -K to activate LVs within that VG. I think the `--setautoactivation n` flag for VGs/LVs only affects autoactivation (e.g. `vgchange -aay`, as done by udev, or `lvchange -aay`), not manual activation (e.g. `vgchange -ay`/`lvchange -ay`). > >>> 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. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
