Fabian Ebner [Thu, 22 Oct 2020 10:30:13 +0000 (12:30 +0200)]
backup: include IDs for non-existent guests
Like this, there will be a backup task (within the big worker task)
for such IDs, which will then visibly (i.e. also visible in the
notification mail) fail with, e.g.:
unable to find VM '123'
In get_included_guests, the key '' was chosen for the orphaned IDs,
because it cannot possibly denote a nodename.
At the moment it might not be possible to trigger this anymore,
because of the guest inclusion rework that happened later on.
But to make tasks for inexistent guest IDs visibly fail again,
this check will be necessary. Also, to get the error message in
the mail, it needs to fail inside the eval block.
Thus, keep the check in the eval block and move the block of code
using the plugin to below the check.
Dominik Csapak [Mon, 19 Oct 2020 14:15:25 +0000 (16:15 +0200)]
partially fix #3056: namespace vzdump tmpdir with vmid
this fixes an issue where a rogue running backup would upload the vm
config of a later backup in a backup job
instead now that directory gets deleted and the config is not
available anymore
we cannot really keep those directories around until the end of the
backup job, since we temporarily save ct contents there, which could get
large very fast
Stefan Reiter [Tue, 6 Oct 2020 13:32:18 +0000 (15:32 +0200)]
ui: improve boot order editor
The new boot order property can express many more scenarios than the old
one. Update the editor so it can handle it.
Features a grid with all supported boot devices which can be reordered
using drag-and-drop, as well as toggled on and off with an inline
checkbox.
Support for configs still using the old format is given, with the first
write automatically updating the VM config to use the new one.
The renderer for the Options panel is updated with support for the new
format.
Note that it is very well possible to disable all boot devices, in which
case an empty 'boot: ' will be stored to the config file. I'm not sure
what that would be useful for, but there's no reason to forbid it
either, just warn the user that it's probably not what they want.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Aaron Lauterer [Thu, 1 Oct 2020 12:18:40 +0000 (14:18 +0200)]
ui: FirewallRules.js: fix #3049 wider rule number column
Allows 2 digits rule numbers to be visible in the column. Made it a bit
wider than needed to account for potentially wider font rendering on
different platforms.
and make the two options mutally exclusive as long
as they are specified on the same level (e.g. both
from the storage configuration). Otherwise prefer
option > storage config > default (only maxfiles has a default currently).
Defines the backup limit for prune-backups as the sum of all
keep-values.
There is no perfect way to determine whether a
new backup would trigger a removal with prune later:
1. we would need a way to include the not yet existing backup
in a 'prune --dry-run' check.
2. even if we had that check, if it's executed right before
a full hour, and the actual backup happens after the full
hour, the information from the check is not correct.
So in some cases, we allow backup jobs with remove=0, that
will lead to a removal when the next prune is executed.
Still, the job with remove=0 does not execute a prune, so:
1. There is a well-defined limit.
2. A job with remove=0 never removes an old backup.
if the checkbox is not checked, we set the value of the vmid filter to ''
but left 'exactMatch' enabled, which means we filter all out where
the vmid is not ''
what we instead want is to remove also the exactMatch so that we
get *all* entries back not *none*
Fabian Ebner [Thu, 27 Aug 2020 11:16:55 +0000 (13:16 +0200)]
ContentView: block removal of in-use container image
Since commit 5dae1a319b32ea3ebbb0b48a9f0b5e3abd1833c9 in pve-storage,
list_volumes correctly returns content type 'rootdir' for container images.
Adapt the relevant check here to make removal behave like it does
for VM images again.
Aaron Lauterer [Tue, 4 Aug 2020 09:46:38 +0000 (11:46 +0200)]
backup: fix #2913 order jobs numerically by VMID
At this point, the VMIDs are already numerically sorted by the
PVE::VZDump::check_vmids method. Calling another sort on the array,
especially without `{$a <=> $b}`, resulted in reordering the array
alphabetically.
Thomas Lamprecht [Fri, 24 Jul 2020 17:11:28 +0000 (19:11 +0200)]
ui: Proxmox Backup: allow to autogenerate an encryption key
a bit more complicated than wished, but if we want to have at least a
bsaic OK user experience we need to give good feedback that the key
will be deleted.
We definitively want to extend this, allow uploading their own,
export if root@pam, only move not delete on "removal", for safety.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In some situations Ceph's auto-detection doesn't recognize the device
class correctly. The option allows to set it directly on osd create,
instead of altering it afterwards. This way the cluster doesn't need to
shift data back and forth unnecessarily.
shows a runningChart (like for reads) for the recovery speed
also shows a progressbar of the health percentage of the cluster
with an estimate of how long the recovery might need
(unhealthy objects) / (objects per second)
only show them when a recovery is ongoing or there are unhealthy
objects
VZDump: add TARFILE to environment for hookscripts
The renaming of tarfile to target in 6cba1855d801545df3f3f81619dfa11cf2501858
can break existing vzdump hook scripts of users.
by setting the TARFILE variable in addition to TARGET the scripts will continue
to work.
fix #2609 gui: backup: add window for not backed guests
In case that there are guests which are not covered by any backup job, a
notification is shown and a window with a grid can be opened to view
these guests.
fix #2609 api: backupinfo: add non job specific endpoint
Adds a new api endpoint at cluster/backupinfo for cluster wide backup
stuff. This is necessary because cluster/backup expects a backup job ID
at the next level and thus other endpoints are hard to impossible to
implement under that hierarchy.
The only api endpoint available for now is the `not_backed_up` which
returns a list of all guests which are not covered by any backup job.
The top level index endpoint is left unsused for now to be available for
a more generic summary endpoint in the future.
The new detail view for backup jobs shows the settings similar to the
edit dialog but read only. Additionally it does show a list of all
included guests with their volumes and whether these volumes will be
included in the backup.
vzdump: included_guest: return empty hash if no guests selected
This will fix the behaviour when calling `vzdump --stop` to cause all
local guests to be backed up.
When refactoring this logic in commit df5875b4, the assumption was that
every call will have one of the following parameters set: pool, list of
VMIDs or all (intentional or when exclude is used).
There is an addtional possibility, that vzdump is called with only
--stop. Thus there are no other parameters that would indicate which
VMIDs to include.
Even now we can have plain vma files which, while an archive, are not
a TARfile.
Use the generic (backup) target as key instead. Makes it less
confusing to be reused for PBS in a later patch.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
projects / pve-manager.git / log