From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 8B1C791047 for ; Fri, 26 Jan 2024 12:15:30 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5CC3234554 for ; Fri, 26 Jan 2024 12:15:00 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 26 Jan 2024 12:14:59 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 1930F492DB for ; Fri, 26 Jan 2024 12:14:59 +0100 (CET) Message-ID: Date: Fri, 26 Jan 2024 12:14:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Proxmox VE development discussion , Friedrich Weber References: <20240111150332.733635-1-f.weber@proxmox.com> From: Fiona Ebner In-Reply-To: <20240111150332.733635-1-f.weber@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.074 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH storage 0/2] fix #4997: lvm: avoid autoactivating (new) LVs after boot X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2024 11:15:30 -0000 Am 11.01.24 um 16:03 schrieb Friedrich Weber: > By default, LVM autoactivates LVs after boot. In a cluster with VM disks on a > shared LVM VG (e.g. on top of iSCSI), this can indirectly cause guest creation > or VM live-migration to fail. See bug #4997 [1] and patch #2 for details. > > The goal of this series is to avoid autoactivating LVs after boot. Fabian > suggested to use the "activation skip" flag for LVs. LVs with that flag can > only be activated if the `-K` flag is passed during activation (`-K` is not > passed for autoactivation after boot). > > With patch #1, the LVM plugin passes the `-K` flag to activation commands. If > the LV does not have the "activation skip" flag set, this should not have any > effect, so it should be safe to apply this patch in the near future. It does > not yet fix #4997, though. > > With patch #2, the LVM plugin sets the "activation skip" flag for newly created > LVs. As this can be considered a breaking change, it may make sense to only > apply it close to the PVE 9 release. If patch #1 has been available in the last > PVE 8 minor release, this should ensure a smooth upgrade even if a cluster is > temporarily mixed between PVE 8.x and 9 (PVE 8.x will be able to activate LVs > created by PVE 9 with "activation skip"). This will fix #4997 for newly created > LVs. > Yes, patch #2 can cause issues for clusters with mixed minor versions, so I'd consider this a breaking change. > 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. 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 ;) > * Even with patch #1 and #2 applied, users can still run into #4997 for LVs > that were created before #2, so without the "activation skip" flag. So it might > be good to include a note in the 8->9 release notes and/or a warning in the > pve8to9 helper and/or ship a script that automatically sets the flag for all > existing (PVE-owned) LVs. > Sure, mentioning the changed behavior and suggestion/script for making it consistent make sense.