[pve-devel] [PATCH qemu-server v2 05/15] api: remove unusable default storage parameter in check_storage_access

[Fiona Ebner]

Am 21.02.25 um 09:27 schrieb Daniel Kral:
> On 2/20/25 15:09, Fiona Ebner wrote:
>> Am 11.02.25 um 17:08 schrieb Daniel Kral:
>>> Since 0541eeb8 ("use property strings for drive options") the user input
>>> of a volume with allocation support must be a pair of a PVE-managed
>>> storage and an arbitrary string (i.e. the volume name or the size of a
>>> new disk in GB) [0]. Therefore, the `$volid` must always be the string
>>> "$storeid:$volname_or_size" for cloudinit images and new disks.
>>> Therefore, the `$default_storage` parameter is redundant.
>>>
>>> Remove it as it is rejected by `verify_volume_id_or_qm_path` for
>>> allocatable disk drives before calling this subroutine anyway, which is
>>> used by both API handlers, i.e. `create_vm` and `update_vm`, that call
>>> the subroutine.
>>>
>>> [0] except the special cases "none", "cdrom" and absolute paths, which
>>>      were introduced some time later with `pve-volume-id-or-absolute-
>>> path`
>>>      and `pve-volume-id-or-qm-path`.
>>>
>>> Signed-off-by: Daniel Kral <d.kral at proxmox.com>
>>> ---
>>> changes since v1:
>>> - new!
>>>
>>>   PVE/API2/Qemu.pm | 11 ++++-------
>>>   1 file changed, 4 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
>>> index 5ac61aa5..2a2d971e 100644
>>> --- a/PVE/API2/Qemu.pm
>>> +++ b/PVE/API2/Qemu.pm
>>> @@ -133,7 +133,7 @@ my $check_drive_param = sub {
>>>   };
>>>     my $check_storage_access = sub {
>>> -   my ($rpcenv, $authuser, $storecfg, $vmid, $settings,
>>> $default_storage, $extraction_storage) = @_;
>>> +   my ($rpcenv, $authuser, $storecfg, $vmid, $settings,
>>> $extraction_storage) = @_;
>>>        $foreach_volume_with_alloc->($settings, sub {
>>>       my ($ds, $drive) = @_;
>>> @@ -143,13 +143,11 @@ my $check_storage_access = sub {
>>>       my $volid = $drive->{file};
>>>       my ($storeid, $volname) = PVE::Storage::parse_volume_id($volid,
>>> 1);
>>>   -    if (!$volid || ($volid eq 'none' || $volid eq 'cloudinit' ||
>>> (defined($volname) && $volname eq 'cloudinit'))) {
>>> +    if (!$volid || ($volid eq 'none' || (defined($volname) &&
>>> $volname eq 'cloudinit'))) {
>>>           # nothing to check
>>>       } elsif ($isCDROM && ($volid eq 'cdrom')) {
>>>           $rpcenv->check($authuser, "/", ['Sys.Console']);
>>>       } elsif (!$isCDROM && ($volid =~
>>> $PVE::QemuServer::Drive::NEW_DISK_RE)) {
>>> -        my $storeid = $2 || $default_storage;
>>
>> The rest looks fine, but I'd rather keep the assignment with the result
>> from the regex match here. Because otherwise, the code would rely on
>> parse_volume_id() to work for everything matching the regex and that is
>> a pretty implicit assumption and might not stay true in the future.
> 
> Hm, the reason why I did it this way was so that the following fix for
> cloudinit drives could be written a little bit cleaner as they both need
> the same storage access checks, so I don't need to duplicate the same
> core logic.
> 
> I guess I could leave, but I'd have to fallback the `$storeid` provided
> by `parse_volume_id()` for the cloudinit case then, as $2 will not
> contain anything since the NEW_DISK_RE regex was unsuccessful (captures
> only if the $storeid follow a digit). Would that way work for you?

Yes. You could also add a $is_new_disk variable and do the check up
front to make the code cleaner.

> 
> I guess a cleaner way to do this in the future is to make `NEW_DISK_RE`
> depend on the regex of the "pve-volume-id" format as much as possible
> (e.g. the now required $storeid prefix), but that'd be beyond this patch
> series and one should take a closer look before doing this.

No, I don't think those should be tightly coupled. For example,
parse_volume_id() might be restricted to not work for storeid:number at
some point.