From: "Max R. Carrara" <m.carrara@proxmox.com>
To: "Elias Huhsovitz" <e.huhsovitz@proxmox.com>,
<pve-devel@lists.proxmox.com>
Subject: Re: [PATCH storage] fix #7811: storage: lvm: reject allocation on format and volume name mismatch
Date: Tue, 21 Jul 2026 14:50:32 +0200 [thread overview]
Message-ID: <DK49GDXP4EOO.1POO9KBS7MEGA@proxmox.com> (raw)
In-Reply-To: <20260716103243.61836-1-e.huhsovitz@proxmox.com>
On Thu Jul 16, 2026 at 12:32 PM CEST, Elias Huhsovitz wrote:
> 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.
Gave this a spin on my local development VM and can confirm that the
check prevents allocating new qcow2 disks if the filename doesn't end
with .qcow2.
In particular, this fails:
pvesh create /nodes/localhost/storage/lvm-thick/content \
--filename vm-116-disk-1 \
--size 4G \
--vmid 116 \
--format qcow2
But this succeeds:
pvesh create /nodes/localhost/storage/lvm-thick/content \
--filename vm-116-disk-1.qcow2 \
--size 4G \
--vmid 116 \
--format qcow2
Just for completeness' sake, I also tested this with a regular `dir`
storage to see if the behavior is the same now -- and indeed it is!
So, what this this commit implements matches the expected behavior.
The code is also neat; very nice that you're using `my sub` for the
helper you're adding. The only thing that's missing is a `make tidy`
run, but honestly, since that only changes one line (see below), I think
it can just be run when applying this IMO.
Therefore, consider:
Reviewed-by: Max R. Carrara <m.carrara@proxmox.com>
Tested-by: Max R. Carrara <m.carrara@proxmox.com>
>
> 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 => '',
^ this guy here gets un-indented by `make tidy`.
> + 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;
prev parent reply other threads:[~2026-07-21 12:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 10:32 [PATCH storage] fix #7811: storage: lvm: reject allocation on format and volume name mismatch Elias Huhsovitz
2026-07-21 12:50 ` Max R. Carrara [this message]
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=DK49GDXP4EOO.1POO9KBS7MEGA@proxmox.com \
--to=m.carrara@proxmox.com \
--cc=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