On Thu, Oct 15, 2026 at 10:34:14AM -0700, Pierrick Bouvier wrote: > Hi Daniel, > > On 10/15/2026 4:20 AM, Daniel P. Berrangé 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 > > * 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'. > > > > There is a open question in one of the patches about SIGBUS > > handling, since that is already used for MCE capture and I'm > > unclear if I'm breaking something about KVM MCE reporting. > > > > This series proposes using sigaltstack() to register an > > alternative signal handling stack. This would mainly be > > useful if we have a crash from a stack overflow, but the > > cost is that we have 8k extra per thread, and I'm not > > entirely convinced that's a beneficial tradeoff. Might > > be better to just accept stack overflows as a risk. > > > > This series only captures text based info, but as a followup > > I would like to extend this to capture statistics data from > > relevant subsystems. For example, the BlockBackend has its > > own "always on" stats accounting code, which can be queried > > with QMP. Ideally I would like to figure out a way to dump > > all the BlockBackend stats in the data recorder output. > > Likewise perhaps capture NIC stats and/or KVM stats in an > > "always on" manner for some interesting baseline dataset. > > The challenge with that is making it safe to access the > > stats data without taking any mutex locks, since this must > > run from a signal handler. > > > > A typical recommended usage would be: > > > > $QEMU -object tldr-config,id=tldr > > -d tldr > > -trace events=/var/lib/libvirt/qemu/trace.txt > > > > This leaves dumps to go to QEMU's stderr on crash, but > > to send them to a file > > > > -object tldr-config,id=tldr,crash-target=/some/path > > > > The '-d tldr' flag redirects qemu_log() to the TLDR buffer > > instead of stdout, and the '-trace events' arg defines > > the "always on" tracepoints we want to capture. > > > > if I understand correctly, the goal of this new object is to provide a > per-topic rotating log in memory that will be flushed on disk only when > we have a specific event (exit, or any signal). That's sounds like a > good idea! > > Why not refactor exisiting trace/log and provide the same feature > directly there? This would be transparent, and user could decide to > either dump the full file (same than before) or benefit from rotating > memory buffered, with any custom size. > > $QEMU -d category,size=4M -trace events=out,max-size=16M
The data recorder is intended to report more than just textual log messages. This series already captures signal info, and as noted in the cover letter will also be extended to capture structured data items such as performance statistics. The text based messages are just the simple first step. That said I'll think about whether the split of responsibilities should adjust so that some of the logic is exposed more broadly into the log system. 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 :|
