On 9/1/26 13:00, Peter Krempa wrote:
On Tue, Sep 01, 2026 at 12:48:32 +0200, Claudio Fontana wrote:
On 9/1/26 11:35, Daniel P. Berrangé wrote:
On Tue, Sep 01, 2026 at 10:11:04AM +0200, Claudio Fontana wrote:
On 9/1/26 00:53, Jim Fehlig wrote:
On 8/31/26 9:34 AM, Peter Krempa wrote:
On Fri, Aug 28, 2026 at 14:16:17 -0600, Jim Fehlig via Devel wrote: > From: Jim Fehlig <jfehlig@suse.com>
[...]
The whole TERM, wait 10 seconds, KILL, wait 30 seconds approach was designed from the POV that a normally behaving QEMU will "die" very quickly. IOW, any scenario where we reached the KILL stage was almost certainly a broken QEMU/kernel in some respect.
Clearly this is no longer a valid assumption. When "normal" behaviour or QEMU no longer matches libvirt's default mgmt action behaviour then I don't think a global qemu.conf setting or a per-VM setting is the ideal approach.
We need to ensure libvirt "does the right thing" out of the box, as best as we can.
Hi Daniel,
in principle I agree it would be the best outcome, just seems hard to get it right.
IMHO, this suggests we need to dynamically increase our wait time before KILL based on the guest RAM size. eg Add 5 seconds for each 100 GB of small page RAM. I pulled that number out of the air, you would need to pick something better based on a typical system, plus some buffer/fuzz.
Also I've noticed that TDX guests are painfully slow to teardown, even with tiny RAM sizes. So we might need to increase wait times even more when using TDX.
Indeed. And like this there are many more factors that can change the result substantially (hugepages settings, NUMA, cpu and load state @memory controller, ...).
Each one of these factors would need to be extracted or sampled and multiplied for the total RAM size.
In one case I have seen two CPUs of the same generation, ~ same # of sockets, same base clock, (but slightly different CPU model), same hugepages settings, comparable NUMA topology ... differ in terms of QEMU process termination times by a factor of at least 4, _presumeably_ due to a combination of slower memory speeds coupled with heavy memory-intensive workloads on the same socket.
I am concerned that getting to the "right" number might prove impractical?
The same thing applies to a config option too. And much more for a global one, as the size of the VM may differ. If there is no good way to determine the correct value, users who would want to set the config option will also have difficult time setting the correct value in the config option.
Not the same thing at all. The difference being, the users have the actual hardware system to test on, they are in control of their host configuration, and _can_ sample and monitor system load and the QEMU process shutdown times _in their environment_. These are all things that are almost impossible to do from the libvirt code. And surely a global config is better than the magic hardcoded "let it be 40" number we have now? Thanks, Claudio