From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id D15191FF176 for <inbox@lore.proxmox.com>; Fri, 7 Feb 2025 13:45:15 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 004BAA801; Fri, 7 Feb 2025 13:45:12 +0100 (CET) Message-ID: <174a386d-2c1e-4023-acf0-2c3d0ea1417d@proxmox.com> Date: Fri, 7 Feb 2025 13:44:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Friedrich Weber <f.weber@proxmox.com> To: pve-devel@lists.proxmox.com References: <20240111150332.733635-1-f.weber@proxmox.com> Content-Language: en-US In-Reply-To: <20240111150332.733635-1-f.weber@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.001 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record 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 <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> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> On 11/01/2024 16:03, Friedrich Weber wrote: > 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). I revisited this issue now, and with some distance, I wondered why to go with the quite heavy-handed approach of - (1) activating LVs with -K/--ignoreactivationskip - (2) starting with PVE 9, creating LVs with -k/`--setactivationskip y` If it would be possible to instead just create new LVs with `--setautoactivation n`, we wouldn't need to touch the activation code at all, and wouldn't need to worry about the mixed-version cluster scenario. For VGs on iSCSI volumes, setting `--setautoactivation n` on LVs seems to work fine -- this way, after iSCSI login, these volumes are not automatically activated. The reason is that autoactivation is done by udev via /lib/udev/rules.d/69-lvm.rules: IMPORT{program}="/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output $env{DEVNAME}" TEST!="/run/systemd/system", GOTO="lvm_direct_vgchange" ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="/usr/bin/systemd-run --no-block --property DefaultDependencies=no --unit lvm-activate-$env{LVM_VG_NAME_COMPLETE} /sbin/lvm vgchange -aay --autoactivation event $env{LVM_VG_NAME_COMPLETE}" GOTO="lvm_end" LABEL="lvm_direct_vgchange" ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="/sbin/lvm vgchange -aay --autoactivation event $env{LVM_VG_NAME_COMPLETE}" GOTO="lvm_end" In both branches vgchange is called with `-aay` where `ay` specifies autoactivation, which according to `man vgchange` doesn't activate LVs with `--setautoactivation n`. However, for VGs on FC/SAS+multipath disks (these are visible at boot time), even an LV with `--setautoactivation n` is active after boot. I was curious why, and I *think* (see [2] for info how to debug this) it's because they are already activated in initramfs (because they are visible at boot time): - 69-lvm.conf does in fact call vgchange with `-aay`, and does not activate LVs with `--setautoactivation n`, as expected - but zfs-initramfs also installs a script /usr/share/initramfs-tools/scripts/local-top/zfs [1] to initramfs which calls: /sbin/lvm vgscan /sbin/lvm vgchange -a y --sysinit Note that it calls `vgchange -ay` (instead of `vgchange -aay`) so LVM doesn't consider this autoactivation and activates all LVs regardless of their `--setautoactivation` flag. If I edit the script to use `-aay` instead, the LV with `--setautoactivation n` flag is inactive after boot as expected. So I'm wondering: (a) could the ZFS initramfs script use `-aay` instead of `-ay`, so the `--setautoactivation` flag has an effect again for LVs that are visible at boot? (b) assuming (a) can be fixed, is there any additional reason to prefer to --ignoreactivationskip/--setactivationskip approach over the `--setautoactivation n` approach? [1] https://github.com/openzfs/zfs/blob/c2458ba921a8d59cd6b705f81b37f50531f8670b/contrib/initramfs/scripts/local-top/zfs [2] FWIW, one way to debug this: - attaching a serial console to the VM - removing `quiet` and adding `console=ttyS0` to the kernel command line - setting `log_level=debug` in /usr/share/initramfs-tools/scripts/init-top/udev - adding some debug printouts (echo XYZ > /dev/ttyS0) to /usr/share/initramfs-tools/scripts/local-top/zfs - don't forget `update-initramfs -u` - attach to serial console on host: `qm console VMID` _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel