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 54FD01FF16F
for <inbox@lore.proxmox.com>; Tue, 29 Apr 2025 13:37:34 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 1C7BAACB2;
Tue, 29 Apr 2025 13:37:32 +0200 (CEST)
From: Friedrich Weber <f.weber@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Tue, 29 Apr 2025 13:36:43 +0200
Message-Id: <20250429113646.25738-4-f.weber@proxmox.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250429113646.25738-1-f.weber@proxmox.com>
References: <20250429113646.25738-1-f.weber@proxmox.com>
MIME-Version: 1.0
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.008 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. [proxmox.com, lvmthinplugin.pm, gitlab.com]
Subject: [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>
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
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 {
--
2.39.5
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel