[pve-devel] [PATCH pve-storage v2 5/5] vdisk_alloc: add optional assertion for volume's content type

[Fiona Ebner]

Am 11.02.25 um 17:07 schrieb Daniel Kral:
> Allow a caller to specify the volume's intended content type and assert
> whether the specified content type may be stored on the specified
> storage before allocating any volume.
> 
> Signed-off-by: Daniel Kral <d.kral at proxmox.com>
> ---
> changes since v1:
> - add assertion at `vdisk_alloc` instead of wrapper `alloc_volume_disk`
> 
>  src/PVE/Storage.pm | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/src/PVE/Storage.pm b/src/PVE/Storage.pm
> index 3776565..96d4e41 100755
> --- a/src/PVE/Storage.pm
> +++ b/src/PVE/Storage.pm
> @@ -1059,6 +1059,13 @@ Specifies the name of the new volume.
>  
>  If undefined, the name will be generated with C<PVE::Storage::Plugin::find_free_diskname>.
>  
> +=item * C<< $vtype => $string >>
> +
> +Specifies the content type of the new volume, which can be one of C<'images'>, C<'rootdir'>,
> +C<'vztmpl'>, C<'iso'>, C<'backup'>, C<'snippets'> or C<'import'>.

Hmm, vdisk_alloc() is only for allocating guest and import images. So I
think the other content types should be prohibited here (can still be
extended later if it ever comes up).

We plan to better distinguish between 'rootdir' and 'images' in the
future, so I think we should aim to make the $vtype parameter even
required here. Not quite possible yet, because that would require
breaking 'pvesm alloc', but we can postpone that part for PVE 9 and have
all other callers already use it.

So my question is if we should rather make it a required parameter
already rather than putting it into $opts? I mean while supporting
passing in undef too, until we are ready to require it for 'pvesm alloc'
too.

@Fabian sounds good to you too?