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