From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <a.lauterer@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id 5EA7F71034
for <pve-devel@lists.proxmox.com>; Wed, 9 Jun 2021 16:21:17 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 4AFE8267CC
for <pve-devel@lists.proxmox.com>; Wed, 9 Jun 2021 16:20:47 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS id 73BCB267BF
for <pve-devel@lists.proxmox.com>; Wed, 9 Jun 2021 16:20:45 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 47CF8465F9
for <pve-devel@lists.proxmox.com>; Wed, 9 Jun 2021 16:20:45 +0200 (CEST)
To: Fabian Ebner <f.ebner@proxmox.com>, pve-devel@lists.proxmox.com
References: <20210601161025.32024-1-a.lauterer@proxmox.com>
<20210601161025.32024-3-a.lauterer@proxmox.com>
<a806aa9e-ba5b-72bf-25b9-247547bf98ad@proxmox.com>
From: Aaron Lauterer <a.lauterer@proxmox.com>
Message-ID: <bcfcf011-233a-ddd5-395a-62bf9637dca6@proxmox.com>
Date: Wed, 9 Jun 2021 16:20:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <a806aa9e-ba5b-72bf-25b9-247547bf98ad@proxmox.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.898 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
KAM_SHORT 0.001 Use of a URL Shortener for very short URL
NICE_REPLY_A -0.001 Looks like a legit reply (A)
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [storage.pm, plugin.pm, gnu.org]
Subject: Re: [pve-devel] [RFC storage 2/7] add disk rename feature
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2021 14:21:17 -0000
Thanks for the review :)
On 6/2/21 10:36 AM, Fabian Ebner wrote:
> Am 01.06.21 um 18:10 schrieb Aaron Lauterer:
>> Functionality has been added for the following storage types:
>>
>>
>> diff --git a/PVE/Storage.pm b/PVE/Storage.pm
>> index 93d09ce..6936abd 100755
>> --- a/PVE/Storage.pm
>> +++ b/PVE/Storage.pm
>> @@ -40,11 +40,11 @@ use PVE::Storage::ZFSPlugin;
>> use PVE::Storage::PBSPlugin;
>> # Storage API version. Increment it on changes in storage API interface.
>> -use constant APIVER => 8;
>> +use constant APIVER => 9;
>> # Age is the number of versions we're backward compatible with.
>> # This is like having 'current=APIVER' and age='APIAGE' in libtool,
>> # see https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
>> -use constant APIAGE => 7;
>> +use constant APIAGE => 8;
>> # load standard plugins
>> PVE::Storage::DirPlugin->register();
>> @@ -355,6 +355,7 @@ sub volume_snapshot_needs_fsfreeze {
>> # snapshot - taking a snapshot is possible
>> # sparseinit - volume is sparsely initialized
>> # template - conversion to base image is possible
>> +# rename - renaming volumes is possible
>> # $snap - check if the feature is supported for a given snapshot
>> # $running - if the guest owning the volume is running
>> # $opts - hash with further options:
>> @@ -1849,6 +1850,20 @@ sub complete_volume {
>> return $res;
>> }
>> +sub rename_volume {
>> + my ($cfg, $source_volid, $source_vmid, $target_volname, $target_vmid) = @_;
>
> Can't the vmid arguments be dropped and extracted directly from the volid/volname instead? Would prevent potential mismatch for careless callers.
Good point
>
>> +
>> + my ($storeid) = parse_volume_id($source_volid);
>> + my (undef, $source_volname, undef, $base_name, $base_vmid, $isBase, $format) = parse_volname($cfg, $source_volid);
>> +
>> + activate_storage($cfg, $storeid);
>> +
>> + my $scfg = storage_config($cfg, $storeid);
>> + my $plugin = PVE::Storage::Plugin->lookup($scfg->{type});
>> +
>
> Check that target_volname is valid (by parsing) either here or within each plugin's implementation?
Will do
>
>> + return $plugin->rename_volume($scfg, $storeid, $source_volname, $source_vmid, $target_volname, $target_vmid, $base_name, $base_vmid);
>
> Similar here, not all plugins need all of those parameters. Isn't taking $scfg, $storeid, $source_volid, $target_volname enough and let the plugin itself extract additional information if needed?
I'll look into it
>
>> +}
>> +
>> diff --git a/PVE/Storage/Plugin.pm b/PVE/Storage/Plugin.pm
>> index 4a10a1f..4e6e288 100644
>> --- a/PVE/Storage/Plugin.pm
>> +++ b/PVE/Storage/Plugin.pm
>> @@ -939,6 +939,7 @@ sub volume_has_feature {
>> snap => {qcow2 => 1} },
>> sparseinit => { base => {qcow2 => 1, raw => 1, vmdk => 1},
>> current => {qcow2 => 1, raw => 1, vmdk => 1} },
>> + rename => { current =>{qcow2 => 1, raw => 1, vmdk => 1} },
>> };
>> # clone_image creates a qcow2 volume
>> @@ -946,6 +947,10 @@ sub volume_has_feature {
>> defined($opts->{valid_target_formats}) &&
>> !(grep { $_ eq 'qcow2' } @{$opts->{valid_target_formats}});
>> + return 0 if $feature eq 'rename'
>> + && $class->can('api')
>> + && $class->api() < 9;
>
> Style-nit: multiline post-if
>
>> +
>> my ($vtype, $name, $vmid, $basename, $basevmid, $isBase, $format) =
>> $class->parse_volname($volname);
>> @@ -1463,4 +1468,28 @@ sub volume_import_formats {
>> return ();
>> }
>> +sub rename_volume {
>> + my ($class, $scfg, $storeid, $source_volname, $source_vmid, $target_volname, $target_vmid, $base_name, $base_vmid) = @_;
>> + die "not implemented in storage plugin '$class'\n" if $class->can('api') && $class->api() < 9;
>> +
>> + my $basedir = $class->get_subdir($scfg, 'images');
>> + my $sourcedir = "${basedir}/${source_vmid}";
>> + my $targetdir = "${basedir}/${target_vmid}";
>> +
>> + mkpath $targetdir;
>> +
>> + my (undef, $format, undef) = parse_name_dir($source_volname);
>> + $target_volname = "${target_volname}.${format}";
>
> Ideally, the $target_volname already contains the format suffix at this point. Otherwise, passing a $target_volname with a format suffix results in a second suffix.
>
I need to look into that as well and do a few tests.