On Wed, Sep 02, 2026 at 04:17:15PM +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 a dump is written, the oldest dumps 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.
Only files named the way getAutoDumpPath() names them count toward the quota, and nothing is pruned when the dump itself failed.
libvirtd_qemu.aug gains a matching entry; its quoted branch requires a unit suffix, as one matching a bare number would overlap the integer branch.
Signed-off-by: Denis V. Lunev <den@openvz.org> --- NEWS.rst | 7 ++ src/qemu/libvirtd_qemu.aug | 4 + src/qemu/qemu.conf.in | 17 ++++ src/qemu/qemu_conf.c | 2 + src/qemu/qemu_conf.h | 1 + src/qemu/qemu_driver.c | 132 +++++++++++++++++++++++++++++ src/qemu/test_libvirtd_qemu.aug.in | 1 + 7 files changed, 164 insertions(+)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> and pushed this whole series. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|