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
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>
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
upstream