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.
