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.k...@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.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
