public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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;





      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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal