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 <[email protected]> > > [...] > >>> 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
