On Fri, Dec 21, 2018 at 10:10 PM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: We discussed this in https://gerrit.ovirt.org/#/c/88109/, you suggested sqlite so we don't have to write a tool to easily search/visualize the metadata. I think sqlite is the easiest way, json requires additional tools to parse/read/search and text is simply unsuitable for this task. The current text output misses several fields and the format may change, parsing text is not efficient. Yes it can happen. In fact it already happens today. In those cases we just ask to collect manually, no big deal if it fails and it shouldn't prevent us from coding more automated collection of this. What we need is this: https://bugzilla.redhat.com/show_bug.cgi?id=1557147 Quite a few: today support needs to ask for storage domain metadata manually (i.e. dd if=/dev/sd/metadata) to fix LSM/Snapshot cases. The idea is to place a sqlite database in the log-collector folder, next to the engine database (not on some random host sosreport) and have a tool to match both databases, pointing to possible issues. Support can easily use sqlite3 from command line on the storage domain sqlite3 database to check what is required to fix the LSM/Snapshot issue. And also serves for us to reduce the back and forth requesting data on support cases. Also this can be consumed by the analyzer that runs automatically these days once a customer uploads logs.