When uploading a '.img' file as import content, '.raw' is appended to
the file name, so the image is always treated as a raw image. But the
'.img' extension is also commonly used for other formats, for example
the Ubuntu cloud images are qcow2 images. Such an image is then
imported as raw disk, which results in a disk with the size of the
qcow2 file and a guest that does not boot.
The format cannot be derived from the '.img' extension, so show a
format selector for such files and only append the extension of the
selected format to the file name. The upload stays disabled until a
format is selected, so the choice is always an explicit one.
Signed-off-by: Michal Fox <me@dualfroz.com>
Link: https://lore.proxmox.com/20260929135840.2748665-2-me@dualfroz.com
For privacy reasons, browsers do not expose the real path of a selected
file and prefix its name with 'C:\fakepath\' instead, on every
platform. The file field of the upload window shows this value as is,
which confuses users on Linux or macOS clients.
Show the name of the selected file object instead. Only the displayed
value changes, the upload itself uses the file object and is not
affected.
Signed-off-by: Michal Fox <me@dualfroz.com>
Reviewed-by: Max R. Carrara <m.carrara@proxmox.com>
Tested-by: Max R. Carrara <m.carrara@proxmox.com>
Link: https://lore.proxmox.com/20260926084935.7-1-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>
The API only allows backup job IDs of up to 50 characters, so mark
longer values as invalid in the edit window already, instead of failing
on submit.
Signed-off-by: Michal Fox <me@dualfroz.com>
The guest list in the backup job editor filters the resource store by
the selected pool. With a plain string value, ExtJS matches any pool
that starts with it, ignoring case, so selecting 'Clients' also listed
the guests of 'Clients/Client1', 'Clients/Client2' and 'clients'.
The job itself only backs up the guests of the selected pool, so the
editor suggested that guests are covered which are not.
Match the pool id exactly and case-sensitively.
Signed-off-by: Michal Fox <me@dualfroz.com>
The memory usage column of the node selector, used e.g. in the
migration dialog, and of the HA node priority selector shows a
percentage, but uses the raw 'mem' bytes as data index. Sorting by that
column thus sorts by used bytes, which does not match the displayed
values as soon as the nodes have a different amount of memory.
Add a calculated 'memuse' field, like the resource store already has,
and use it for the column. This also makes the percentage renderer
receive a ratio here, like everywhere else, which allows dropping its
bytes fallback in a follow-up.
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>
render_mem_usage_percent() treated any value above 1 as a byte count
and recalculated the percentage from 'mem' and 'maxmem'. But the memory
usage ratio of a guest can legitimately exceed 1, for example when the
reported usage is the host-side memory of the QEMU process, which
includes its own overhead. In the reported case, 'mem' was 2222472192
with a 'maxmem' of 2147483648, so the ratio of about 1.035 got taken as
bytes and the search and resource grids showed 0.0 % instead of 103.5 %.
All users of the renderer now pass the usage as a ratio, so drop the
bytes fallback and always render the value as percentage.
Signed-off-by: Michal Fox <me@dualfroz.com>
dualfroz