Hi,
Unless I've totally missed it, or there's a trick to do such a thing, I'd have a little wish for a little enhancement on pool based backup: by allowing multiple pools being selected in a job (or excluded for an inverted effect, as you can do with the "include/exclude VM")
Today, when we manage multiple pools (prod/dev/clients/personnal pools of VMs/CTs) we need to have multiple jobs for each pool, especially if you want to back them up to different destinations and/or namespaces.
The issue being, once in a while, some CTs or VMs takes a bit of time to get vzdumped, pushing the end of the job way beyond the one hour timeout of a potential following job withing for the vzdump lock...
Changing the "Pool Based" > "Pool Selection" to a "Pool(s) Selection" with a multi-select dropdown would already be a step forward, the code change shouldn't even be too hard to do, right ?
Thanks
Unless I've totally missed it, or there's a trick to do such a thing, I'd have a little wish for a little enhancement on pool based backup: by allowing multiple pools being selected in a job (or excluded for an inverted effect, as you can do with the "include/exclude VM")
Today, when we manage multiple pools (prod/dev/clients/personnal pools of VMs/CTs) we need to have multiple jobs for each pool, especially if you want to back them up to different destinations and/or namespaces.
The issue being, once in a while, some CTs or VMs takes a bit of time to get vzdumped, pushing the end of the job way beyond the one hour timeout of a potential following job withing for the vzdump lock...
Changing the "Pool Based" > "Pool Selection" to a "Pool(s) Selection" with a multi-select dropdown would already be a step forward, the code change shouldn't even be too hard to do, right ?
Thanks
