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 [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id F1C9E1FF16F for <inbox@lore.proxmox.com>; Tue, 10 Jun 2025 17:00:19 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 97DF91F1C7; Tue, 10 Jun 2025 17:00:41 +0200 (CEST) Message-ID: <c8ce5e46-bf86-44bf-91ed-c529d935ceb4@proxmox.com> Date: Tue, 10 Jun 2025 17:00:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Friedrich Weber <f.weber@proxmox.com> References: <20250429113646.25738-1-f.weber@proxmox.com> <20250429113646.25738-4-f.weber@proxmox.com> Content-Language: en-US From: =?UTF-8?Q?Michael_K=C3=B6ppl?= <m.koeppl@proxmox.com> In-Reply-To: <20250429113646.25738-4-f.weber@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.016 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [lvmthinplugin.pm, proxmox.com, gitlab.com] Subject: Re: [pve-devel] [PATCH pve-storage v3 3/3] lvmthin: disable autoactivation for new logical volumes 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 4/29/25 13:36, Friedrich Weber wrote: > When discovering a new volume group (VG), for example on boot, LVM > triggers autoactivation. With the default settings, this activates all > logical volumes (LVs) in the VG. Activating an LV creates a > device-mapper device and a block device under /dev/mapper. > > Autoactivation is problematic for shared LVM storages, see #4997 [1]. > For the inherently local LVM-thin storage it is less problematic, but > it still makes sense to avoid unnecessarily activating LVs and thus > making them visible on the host at boot. > > Hence, disable autoactivation after creating new LVs. As lvcreate > doesn't accept the --setautoactivation flag for thin LVs, this is done > with an additional lvchange command. With this setting, LVM > autoactivation will not activate these LVs, and the storage stack will > take care of activating/deactivating LVs when needed. > > [1] https://bugzilla.proxmox.com/show_bug.cgi?id=4997 > > Signed-off-by: Friedrich Weber <f.weber@proxmox.com> > --- > > Notes: > - would be great to get your opinion on whether we should consider > LVM-thin storages in this series or not. > > - passing --setautoactivation n to lvcreate for a thin volume says: > > Option --setautoactivation is unsupported with thins. > > But lvchange --setautoactivation seems to work on thin LVs, so the > fact that lvcreate doesn't accept it may be a bug. I reported it > upstream [1]. > > new in v3 > > [1] https://gitlab.com/lvmteam/lvm2/-/issues/32 Since the upstream issue has not been addressed yet and the change to LVM-thin does, AFAICT, not mitigate problems like in #4997 (or am I missing something here?), but is mostly done to streamline behavior, could the changes for LVM-thin be held back until it's clear that lvcreate not supporting --setautoactivation for LVM-thin is not on purpose? > > src/PVE/Storage/LvmThinPlugin.pm | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/src/PVE/Storage/LvmThinPlugin.pm b/src/PVE/Storage/LvmThinPlugin.pm > index 49a4dcb..3f75ba1 100644 > --- a/src/PVE/Storage/LvmThinPlugin.pm > +++ b/src/PVE/Storage/LvmThinPlugin.pm > @@ -82,6 +82,19 @@ sub filesystem_path { > return wantarray ? ($path, $vmid, $vtype) : $path; > } > > +# lvcreate refuses --setautoactivation for thin volumes, so set it via lvchange > +my $set_lv_autoactivation = sub { > + my ($vg, $lv, $autoactivation) = @_; > + > + my $cmd = [ > + '/sbin/lvchange', > + '--setautoactivation', $autoactivation ? 'y' : 'n', > + "$vg/$lv" > + ]; > + eval { run_command($cmd); }; > + warn "could not set autoactivation: $@" if $@; > +}; > + > sub alloc_image { > my ($class, $storeid, $scfg, $vmid, $fmt, $name, $size) = @_; > > @@ -103,6 +116,7 @@ sub alloc_image { > '--thinpool', "$vg/$scfg->{thinpool}" ]; > > run_command($cmd, errmsg => "lvcreate '$vg/$name' error"); > + $set_lv_autoactivation->($vg, $name, 0); > > return $name; > } > @@ -283,6 +297,7 @@ sub clone_image { > > my $cmd = ['/sbin/lvcreate', '-n', $name, '-prw', '-kn', '-s', $lv]; > run_command($cmd, errmsg => "clone image '$lv' error"); > + $set_lv_autoactivation->($vg, $name, 0); > > return $name; > } > @@ -332,7 +347,7 @@ sub volume_snapshot { > > my $cmd = ['/sbin/lvcreate', '-n', $snapvol, '-pr', '-s', "$vg/$volname"]; > run_command($cmd, errmsg => "lvcreate snapshot '$vg/$snapvol' error"); > - > + # disabling autoactivation not needed, as -s defaults to --setautoactivationskip y > } > > sub volume_snapshot_rollback { > @@ -346,6 +361,7 @@ sub volume_snapshot_rollback { > > $cmd = ['/sbin/lvcreate', '-kn', '-n', $volname, '-s', "$vg/$snapvol"]; > run_command($cmd, errmsg => "lvm rollback '$vg/$snapvol' error"); > + $set_lv_autoactivation->($vg, $volname, 0); > } > > sub volume_snapshot_delete { _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel