[pve-devel] [PATCH/RFC storage] prune backups: activate storage

[Fabian Ebner]

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 at 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