Sosreport is a tool used by support teams from multiple companies (Canonical, Red Hat, more) as the first pass to get enough information to help support a customer problem. Ideally we want it to capture all the info we will need in 90%+ of cases.
You can view the current plugin here: but I’ll break it out as well: https://github.com/sosreport/sos/blob/master/sos/plugins/lxd.py
Files copied
For LXD2.0
/etc/default/lxd-bridge
/var/lib/lxd/lxd.db
More for DEB-based LXD 3.0 - Is DEB based LXD deprecated at this point?
/var/lib/lxd/database/local.db
/var/lib/lxd/database/global/* - is this actually helpful or can we be more selective? See 1921
/var/log/lxd/*
For snap based we don’t have a current list, so help definitely needed, but maybe:
/var/snap/lxd/common/lxd/database/local.db
/var/snap/lxd/common/lxd/logs/*
/var/snap/lxd/common/config
Commands
lxc image list
lxc list
lxc network list
lxc profile list
lxc storage list
And we also do a “find /var/lib/lxd -maxdepth 2 -type d -ls” which we may change to just a recursive ls for all lxd related directories. Are we missing anything key, or can we reduce anything? Thanks!
Indeed, if global database isn’t generally useful we will leave that out. We will just collect local.db as that appears to be small.
Based on the output of buginfo, we will add:
snap info lxd
lxc storage info default
lxc profile show default
lxc cluster list
lxc config show --debug
lxc remote list
lxc version
Doing each command manually just matches how we already use sosreport then using the one buginfo builtin command. If you see any issues with the above, please do let me know. Thanks!
local.db is actually rather useless without the global database too, so I wouldn’t bother.
Sure, you can run the commands manually, but using lxd.buginfo would have the advantage of not needing updates whenever we add a new feature or find something new that’s worth capturing.
Probably doesn’t matter all that much as we’re likely to just ask for lxd.buginfo from anyone giving us a sosreport output anyway
