My question is pretty much directly related to this one.
I am struggling to find some documentation of where configuration for the LXD snap package is stored and how it’s supposed to behave in general in comparison to the Debian package (in my case I care about the Ubuntu flavor of said package).
For example (incomplete list):
what’s the counterpart of /etc/default/lxd-bridge with the snap package?
how do I restart just the dnsmasq instance running as part of the snap package? And, assuming I have to restart the snap service for LXD, how does this affect running containers? This is also interesting for snap in general, which seems to keep a bunch of previous versions … does that mean I can have containers running inside an older instance and the current one?
as per the above linked question I am also wondering if the snap package configuration is tied to the account that installed the snap package in any way (the fact that it’s stored in ~/snap/lxd/current/.config of that account suggests as much)
are there any snap set-able options for the LXD package? If so, which and where is the documentation of those?
where does the information about the lxdbr0 get stored on the file system in case of the snap package being run?
what governs the IP range set? I mean I can see that lxdbr0 exists and has a certain subnet assigned, but where is that information persisted on the file system and how would I go about changing it?
why is the configuration shown by lxc config show empty on a system that had lxd init run on it?
But I am also wondering in general if I am supposed to edit configuration files directly or hand that job to lxc config {set,get,unset} instead?
I also think I found out by now that lxd init doesn’t actually configure lxd in the stricter sense, but instead creates the default profile that is being used for future containers unless otherwise specified. But it’s still beyond me where this information is persisted on disk.
Also, last but not least, how would I go about integrating man pages for the lxd and lxc programs on my host? In particular, is there a better way than the one suggested here? The downside of that method is that I’d have to refresh the output every single time there is an update to the snap package (and possibly purge the old man pages, in case some subcommands go away with newer package versions). While certainly possible, it seems a bit cumbersome (even when using Ansible).
Some of you questions are related to snap packages. I’ll try to answer in the following order, if I miss any, please tell me.
When you install a snap package, the program files are placed in /snap/lxd/current/. In /snap/lxd/ you can also see a few previous versions and you can use snap commands to switch between versions if needed.
The available executables of the snap can be found in /snap/lxd/current/bin/. However, only a few are exposed to the system (the LXD snap package is configured to expose only some of the programs from /snap/lxd/current/bin/ but you can still run anything you find in there (with some caveats)). Those that are exposed, can be found in /snap/bin/.
Each user on a system with snap support, gets a ~/snap/ directory with per-user configuration.
Therefore, ~/snap/lxd/current/.config is the per-user configuration for the LXD snap. This is per-user configuration, and it just has
the list of LXD remotes that you have added.
your aliases, if you added any.
The location for the LXD configuration is in /var/snap/lxd/common/ (common, as in common between LXD version of the snap package). Specifically,
the LXD configuration database at /var/snap/lxd/common/lxd/database/global/db.bin (SQLite). You can view this file with sqlitebrowser.
the running LXD network configuration (managed networks) at /var/snap/lxd/common/lxd/networks/. This is the running configuration. The LXD network configuration is still in the SQLite database file.
sudo lxd init is a wizard that does a set of configurations for you. You could still not run sudo lxd init and configure LXD manually yourself. It would work.
Thanks @simos this clears up all of the questions I had so far and enables me to poke around further on my own. Thanks for that.
Specifically with the knowledge of configuration being stored in an SQLite database enables me to use the SQLite CLI tool to fetch or update specific information.
Through experimentation I also found out that it is the snap.lxd.daemon service that creates/manages the lxdbr0 and so it seems clear that it’ll be sufficient to stop the service, adjust the IP range - for example - and then start it again.
On recent LXD, all network configuration is managed through lxc network, you can edit it through that CLI or using the REST API and changes will be applied immediately.
/etc/default/lxd-bridge was only there during LXD 2.0.x and was deprecated in favor of the native network management API in 2.1.
As for directly messing with the database, it’s obviously not recommended and you may end up in a weird state while doing it. If you do need to do it anyway, you should be using lxd sql local or lxd sql global to run queries against the two databases rather than directly using sqlite3.
Running sqlite3 directly against the global database may look like it works, but none of the changes you make through it will persist. That’s because of the way dqlite actually works as far as on-disk storage.
I use sqlitebrowser (GUI) to read the contents of the LXD database file.
Indeed, making changes with any external tool may mess up LXD in unexpected ways.
Here is sqlitebrowser. I have selected a table, and then I can use the Up/Down arrow keys to easily navigate through all the tables in the database. I can see the columns and also the data. For the purposes of learning what’s in the database, I think it’s really useful.
