From: Elias Huhsovitz <e.huhsovitz@proxmox.com>
To: pve-devel@lists.proxmox.com
Cc: Elias Huhsovitz <e.huhsovitz@proxmox.com>
Subject: [PATCH storage] fix #7811: storage: lvm: reject allocation on format and volume name mismatch
Date: Thu, 16 Jul 2026 12:32:43 +0200 [thread overview]
Message-ID: <20260716103243.61836-1-e.huhsovitz@proxmox.com> (raw)
When users allocate a new volume via the API and request a specific
format (like 'qcow2'), but provide a volume name without the
corresponding extension (like 'vm-100-disk-0'), the generic API
validation misses the inconsistency. This occurs because standard LVM
raw volumes do not use file extensions.
The LVMPlugin ignored this mismatch. It created a raw
logical volume and logged a misleading "formatting as qcow2" message.
This resulted in a confusing state where the storage lists the volume
as 'raw', but the underlying block device contains a 'qcow2' image.
To fix this, add a new file-private subroutine, `verify_volname_format`,
to the LVM plugin. This subroutine compares the requested format with
the format implied by the volume name. If they differ, the plugin
rejects the allocation and provides a hint to correct the
volume name.
Signed-off-by: Elias Huhsovitz <e.huhsovitz@proxmox.com>
---
src/PVE/Storage/LVMPlugin.pm | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/src/PVE/Storage/LVMPlugin.pm b/src/PVE/Storage/LVMPlugin.pm
index a313ecc..3be833e 100644
--- a/src/PVE/Storage/LVMPlugin.pm
+++ b/src/PVE/Storage/LVMPlugin.pm
@@ -738,12 +738,36 @@ my sub alloc_lvm_image {
}
+my %LVM_FORMAT_EXTENSIONS = (
+ raw => '',
+ qcow2 => 'qcow2',
+);
+
+my sub verify_volname_format {
+ my ($class, $name, $fmt) = @_;
+
+ my $expected_ext = $LVM_FORMAT_EXTENSIONS{$fmt};
+ return if !defined($expected_ext);
+
+ my (undef, undef, undef, undef, undef, undef, $parsed_fmt) = $class->parse_volname($name);
+
+ return if $fmt eq $parsed_fmt;
+
+ my $base_name = $name =~ s/\.[^.]+$//r;
+ my $suggested_name = $expected_ext ? "$base_name.$expected_ext" : $base_name;
+
+ die "volume name '$name' does not match requested format '$fmt' "
+ . "(did you mean '$suggested_name'?)\n";
+}
+
sub alloc_image {
my ($class, $storeid, $scfg, $vmid, $fmt, $name, $size) = @_;
$name = $class->find_free_diskname($storeid, $scfg, $vmid, $fmt)
if !$name;
+ verify_volname_format($class, $name, $fmt);
+
alloc_lvm_image($class, $storeid, $scfg, $vmid, $fmt, $name, $size);
return $name;
--
2.47.3
reply other threads:[~2026-07-16 10:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260716103243.61836-1-e.huhsovitz@proxmox.com \
--to=e.huhsovitz@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox