On 7/7/26 11:23, Daniel P. Berrangé wrote: > On Tue, Jul 07, 2026 at 09:48:22AM +0200, Denis V. Lunev via Devel wrote: >> Each on_crash or watchdog-triggered dump writes a full memory dump >> into auto_dump_path. A guest that keeps crashing and restarting (or >> crashing and getting destroyed, then respawned by the mgmt app) can >> fill the disk one dump at a time, with nothing to stop it. >> >> Add auto_dump_max_size (qemu.conf), parsed via virConfGetValueBytes() >> so it takes a plain byte count or a size with a unit suffix (e.g. >> "10GiB"). After each dump attempt, the oldest files under >> auto_dump_path are removed until the total fits the configured quota. >> The dump that was just written is always kept by identity, not by >> sort position: mtime is only second-granularity, so two dumps written >> the same second would otherwise make the eviction order between them >> arbitrary and could delete the one just written instead of an older >> one. Defaults to 0, which keeps every dump forever, as before. > This is a good idea, however, I wonder if we should also have a > global cross-VM limit, as with cloud you might equally see a loop > where a VM fails to spawn and automation spins up a new VM with > different identity each time. > > Perhaps also "auto_dump_min_free_space" where we statfs the dump > location to figure out current free space, subtract the VM RAM > size (as a rough approximation for worst case dump size), and > then reject the dump if the result would be under the limit. > > If you want to do that, it could be a separate followup patch so > no need to repost this series just for that. >
I have tried to implement node-wide limit, not VM specific one. We have global directory (node-wide) and we enumerate all files there, effectively all dumps. Thus this should be summary limit. Den
