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