From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 48803738AD for ; Fri, 16 Apr 2021 10:52:03 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3C1A322289 for ; Fri, 16 Apr 2021 10:51:33 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 firstgate.proxmox.com (Proxmox) with ESMTPS id 2415F2227F for ; Fri, 16 Apr 2021 10:51:32 +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 DD7B542E8F for ; Fri, 16 Apr 2021 10:51:31 +0200 (CEST) From: Fabian Ebner To: pve-devel@lists.proxmox.com Date: Fri, 16 Apr 2021 10:51:27 +0200 Message-Id: <20210416085127.17803-1-f.ebner@proxmox.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.007 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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] Subject: [pve-devel] [PATCH/RFC storage] prune backups: activate storage X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 08:52:03 -0000 which also checks whether the storage is even enabled. VZDump jobs already activate the storage, but more direct calls via API/CLI didn't do so yet. Signed-off-by: Fabian Ebner --- Or should the call rather be made in the API endpoints? For functions like volume_resize, the callers in qemu-server/pve-container do the activation via activate_volumes, while for vdisk_* functions the activation happens directly in the functions. The snapshot-related functions are also currently missing the activation/enabled check! Should the callers in guest-common do an activate_volumes call, or should we do an activate_storage in the functions themselves? The first appraoch has the advantage of being more efficient (one activation call for the whole operation) and also more precise (if volume activation itself is actually needed), while the second one ensures that we do not forget to make the calls. PVE/Storage.pm | 2 ++ 1 file changed, 2 insertions(+) diff --git a/PVE/Storage.pm b/PVE/Storage.pm index 122c3e9..a856266 100755 --- a/PVE/Storage.pm +++ b/PVE/Storage.pm @@ -1630,6 +1630,8 @@ sub prune_backups { $keep = PVE::JSONSchema::parse_property_string('prune-backups', $scfg->{'prune-backups'}); } + activate_storage($cfg, $storeid); + my $plugin = PVE::Storage::Plugin->lookup($scfg->{type}); return $plugin->prune_backups($scfg, $storeid, $keep, $vmid, $type, $dryrun, $logfunc); } -- 2.20.1