public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Friedrich Weber <f.weber@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH storage 0/2] fix #4997: lvm: avoid autoactivating (new) LVs after boot
Date: Wed, 31 Jan 2024 16:07:50 +0100	[thread overview]
Message-ID: <80c410ca-3615-45cc-9801-f1e2d14cab78@proxmox.com> (raw)
In-Reply-To: <c447ba98-649a-40cd-809e-4e120faa1b72@proxmox.com>

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.

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

[1]
https://git.proxmox.com/?p=pve-storage.git;a=blob;f=src/PVE/Storage/LVMPlugin.pm;h=4b951e7a;hb=8289057e#l94




  reply	other threads:[~2024-01-31 15:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 15:03 Friedrich Weber
2024-01-11 15:03 ` [pve-devel] [PATCH storage 1/2] lvm: ignore "activation skip" LV flag during LV activation Friedrich Weber
2024-01-26 11:14   ` Fiona Ebner
2024-01-11 15:03 ` [pve-devel] [PATCH storage 2/2] fix #4997: lvm: set "activation skip" flag for newly created LVs Friedrich Weber
2024-01-26 11:15   ` Fiona Ebner
2024-01-26 11:14 ` [pve-devel] [PATCH storage 0/2] fix #4997: lvm: avoid autoactivating (new) LVs after boot Fiona Ebner
2024-01-31 15:07   ` Friedrich Weber [this message]
2024-02-01  8:26     ` Fiona Ebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=80c410ca-3615-45cc-9801-f1e2d14cab78@proxmox.com \
    --to=f.weber@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal