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