Backups of guests from different teams or users often end up on the
same storage, and the resource pool of the guest is a common way to
tell them apart. But the pool is not part of the backup, and the VMID
alone is not enough to find out later where a backup came from, as
VMIDs can be reused.
Add a {{pool}} variable to the notes template, which is replaced with
the resource pool the guest is a member of at the time of the backup,
or with an empty string if it is not in any pool, and list it in the
hint of the backup dialogs.
Signed-off-by: Michal Fox <me@dualfroz.com>
The type of a storage is sent as a tag, but it is also part of the
storage status data and so sent as a field with the same name.
InfluxDB 3 does not allow this and rejects the whole write with:
'type' is used as both a tag and a field
so no storage metrics end up in the database.
Exclude the type from the fields, like it is already done for the
VMID of guests since commit 456be471 ("fix #3440: influxdb: remove
duplicate vmid tag").
Signed-off-by: Michal Fox <me@dualfroz.com>
When the scheduler checks whether the last run of a job has finished,
it dies if the task log of that run does not exist. The job is then
skipped with 'could not update job state, skipping - no such task' on
every iteration, so it never runs again until its state file is
cleaned up manually.
The task log can be gone, for example after a crash. If the task is
not running anymore, treat it as stopped with an error status instead,
so that the job gets scheduled again, like Proxmox Backup Server does
since commit 48fbce07 ("fix #4895: scheduled jobs: ignore task-log not
found error").
The check now comes after the one whether the task is still running,
so a running task does not get marked as stopped.
Signed-off-by: Michal Fox <me@dualfroz.com>
All backup job API calls that take an existing job ID use the
'pve-backup-jobid' option, which is limited to 50 characters. The
create call uses its own 'id' parameter without that limit, so a longer
ID can be created, but the job can then neither be read, updated nor
deleted through the API or the web UI, and has to be removed from
jobs.cfg by hand.
Apply the same limit when creating the job.
Signed-off-by: Michal Fox <me@dualfroz.com>
A backup job in pool mode keeps referencing its pool after the pool got
deleted. Resolving the guests of such a job dies with "pool '<name>'
does not exist", and since get_included_vmids() did not catch this, the
whole /cluster/backup-info/not-backed-up call failed. The GUI then hides
the "Show guests without backup job" button, so users lose exactly the
overview that would tell them some guests are no longer backed up.
Catch the error per job, warn about it and continue with the remaining
jobs. The broken job does not back up anything, so its guests correctly
show up as not covered by any backup job.
Add a test for get_included_vmids() covering this case.
Signed-off-by: Michal Fox <me@dualfroz.com>
upstream
dualfroz