On 18.11.21 14:28, Dominik Csapak wrote:
previously, systemd timers were responsible for running replication jobs.
those timers would not restart if the previous one is still running.
though trying again while it is running does no harm really, it spams
the log with errors about not being able t
only do the compat fallback if no explicit spice ticket was given, and
warn on unknown parameters on STDIN.
Signed-off-by: Fabian Grünbichler
---
PVE/API2/Qemu.pm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 6830009..8b834bb 100
and update the in-memory config for starting the target VM accordingly.
this possibly breaks migration new -> old iff
- spice is not used (else the explicit ticket wins because it comes
later)
- a local TPM state volume is used
- that local TPM state volume has a different volume id on the target
On 22.11.21 11:30, Fabian Grünbichler wrote:
> only do the compat fallback if no explicit spice ticket was given, and
> warn on unknown parameters on STDIN.
>
> Signed-off-by: Fabian Grünbichler
> ---
> PVE/API2/Qemu.pm | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>
applied, th
On 18.11.21 14:28, Dominik Csapak wrote:
> if '$sub' dies, the error handler of PVE::Daemon triggers, which
> initiates a shutdown of the child, resulting in confusing error logs
> (e.g. 'got shutdown request, signal running jobs to stop')
>
> instead, run it under 'eval' and print the error to th
for some reason, some browsers omit the scroll event if the 'scrollTo'
was done before layouting in some cases, so manually trigger our 'onScroll'
handler to set the new start parameter alwyas after scrolling
Signed-off-by: Dominik Csapak
---
src/panel/LogView.js | 2 +-
1 file changed, 1 insert
improves the handling of fast moving tasks
* no glitching
* catching up to the end of the task log
* workaround browser quirks
Dominik Csapak (3):
ui: logpanel: fix glitching on fast task logs
ui: logpanel: catch up to very fast task logs with api calls
ui: logpanel: work around browser 'set
if we have a task log that produces more lines than we ask for
(start+limit), set the start to the (current) total-limit.
otherwise, keep the logic to set the start so that our current line is
about in the middle of the requested data (to have a buffer in both
directions)
Signed-off-by: Dominik C
when we follow (scrollToEnd === true) a task log that produces many lines
per second, we often get a 'total' back that exceeds our start+limit.
in that case we do not want to pad the bottom of the task log with empty
lines, we only want that for finished task logs to preserve the scroll
bar positi
