Re: [PATCH 00/21] system: introduce a live data recorder facility

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Oct 15, 2026 at 04:15:52PM +0400, marcandre.lureau@redhat.com wrote:
> > This series introduces a new facility called 'tldr' which is a
> > live data recorder. This is intended to aid support of production
> > QEMU deployments, by providing a data collection facility that
> > can be left "always on", such that in the event of a QEMU crash
> > or guest OS crash, certain important information will be recorded.
> > 
> > The data recorder has to be enabled by adding a "tldr-config"
> > object instance with -object / object_add.
> > 
> > With this series, the data recorder collects
> > 
> >  * error_report/warn_report/error_printf messages
> >  * QMP events
> 
> It should probably be recorded at emission, not per monitor

Opps.

> >  * QMP errors
> >  * QMP commands, which are not query-XXX/qom-list,
> >    or any command associated with a QMP error.
> >  * qemu_log output
> > 
> > The last item is intended primarily to be used in combination
> > with tracing and its 'log' backend, to have continuous
> > recording of certain interesting probes.
> > 
> > Each type of data is collected in a distinct circular
> > buffer, such that high volumes of one type of data, does
> > not result in overwriting other types of low volume data.
> > 
> > The data recorder is set to trigger on SIGBUS, SIGSEGV,
> > SIGILL, SIGFPE and SIGABRT, or manually via QMP 'tldr-dump'.
> 
> Instead of allocating and dumping by a signal handler, why not use a file-backed
> mmap or a memfd? We would need to define a small fixed header for the file
> layout/buckets.  This would avoid all the issues with signal handlers.

That would impose a continuous I/O workload on data recording, which
is something I wanted to explicitly avoid, until the time the data is
needed to be preserved. This only persists the final data, not any
intermediate data that is overwritten as the circular buffer wraps.
Coupling the in-memory layout to the on-disk layout also means that
dumps would always be the max size, since we would not have grow-on
demand buffers.

File backed would be even worse for the follow up goal of including
statistics, since it'd be putting disk I/O into the stats gathering
path.

> There would be a small window for consistency on crash, but that's probably
> acceptable.
> 
> Plain ASCII section markers would probably be easier to deal with than emojis



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 :|