From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <f.weber@proxmox.com>
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 902B2C087B
 for <pve-devel@lists.proxmox.com>; Thu, 11 Jan 2024 16:04:18 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 757B116F15
 for <pve-devel@lists.proxmox.com>; Thu, 11 Jan 2024 16:03:48 +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) server-digest SHA256)
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS
 for <pve-devel@lists.proxmox.com>; Thu, 11 Jan 2024 16:03:44 +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 96E2D490D1
 for <pve-devel@lists.proxmox.com>; Thu, 11 Jan 2024 16:03:44 +0100 (CET)
From: Friedrich Weber <f.weber@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Thu, 11 Jan 2024 16:03:30 +0100
Message-Id: <20240111150332.733635-1-f.weber@proxmox.com>
X-Mailer: git-send-email 2.39.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL -0.106 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 -
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [lvmplugin.pm, proxmox.com]
Subject: [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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Thu, 11 Jan 2024 15:04:18 -0000

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.

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?

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

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=4997

storage:

Friedrich Weber (2):
  lvm: ignore "activation skip" LV flag during LV activation
  fix #4997: lvm: set "activation skip" flag for newly created LVs

 src/PVE/Storage/LVMPlugin.pm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


Summary over all repositories:
  1 files changed, 3 insertions(+), 0 deletions(-)

-- 
Generated by git-murpp 0.5.0