From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <f.ebner@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 48803738AD
 for <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; Fri, 16 Apr 2021 10:51:31 +0200 (CEST)
From: Fabian Ebner <f.ebner@proxmox.com>
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 <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: 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 <f.ebner@proxmox.com>
---

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