public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal