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