Where does `lxd init` store its config selections, file or database?

LXD
1

I’m not seeing an lxd config file in /etc/lxc or ~/.config/lxc with the info I specified in lxd init. From this post it sounds like config is stored in a database and only accessible via commandline. Just want to confirm (not clear from the docs either).

I ask because I’m running NixOS as the host, and am evaluating different options for running other guest OS’s in containers or VMs, with a declarative config. Declarative config is easy if lxd’s config is stored in standard /etc config files, but less so if its stored in database.

2

lxd init effectively just issues a bunch of lxc profile, lxc storage, lxc network and lxc config commands (well, their API equivalent).

All of that configures the LXD server which then stores all its config inside the database.

lxd init --preseed lets you provide the whole config in one YAML chunk and lxd init --dump tries to do an approximate of the reverse.

1 Like
3

Thanks! If I can figure out how to set this up declarative in NixOS, will post an update.

4

After digging around a bit, it looks like NixOS uses the LXD/LXC configuration directives in lxc.system.conf 5, lxc-usernet 5, and lxc.container.conf 5 for declarative configuration.

However, it’s not clear how or if some of the options in lxd init --dump map to those configuration options. For example, below is my lxd init --dump. What configuration options do the following init dump options map to:

core.https_address: '[::]:8443'
core.trust_password: true
(there’s no lxd.core or lxc.core option listed in the man pages)

ipv4.nat: "true"
ipv6.nat: "true"
(there’s no obvious “nat” option in the man pages)

source: rpool/local/lxd
volatile.initial_source: rpool/local/lxd
zfs.pool_name: rpool/local/lxd
(might these map to lxc.lxcpath and/or lxc.bdev.zfs.root)

Basically, I need to recreate the lxd init configuration using lxc config directives. I cloned the lxc and lxd git repos to see exactly how lxd init works, but is there an easier way to figure this out?

config:
  core.https_address: '[::]:8443'
  core.trust_password: true
networks:
- config:
    ipv4.address: 10.152.2.1/24
    ipv4.nat: "true"
    ipv6.address: fd42:c9e4:a454:4aae::1/64
    ipv6.nat: "true"
  description: ""
  name: lxdbr0
  type: bridge
  project: default
storage_pools:
- config:
    source: rpool/local/lxd
    volatile.initial_source: rpool/local/lxd
    zfs.pool_name: rpool/local/lxd
  description: ""
  name: lxdpool
  driver: zfs
profiles:
- config: {}
  description: Default LXD profile
  devices:
    eth0:
      name: eth0
      network: lxdbr0
      type: nic
    root:
      path: /
      pool: lxdpool
      type: disk
  name: default
projects:
- config:
    features.images: "true"
    features.networks: "true"
    features.profiles: "true"
    features.storage.volumes: "true"
  description: Default LXD project
  name: default
5

Those are config options for pure LXC (no LXD involved), which we also refer to as liblxc these days to try to clear up some of the confusion.

LXD operates at a higher level and has far deeper abstractions around resources limits, networking and storage than pure LXC does.

Pure LXC does not have a persistent daemon, so things like https address or trust password don’t apply to it. It also doesn’t manage store pools, that’s left to the user, though it can consume them (that’s what the lxc.bdev stuff lets you configure).

6

Ok thanks, I appreciate your time! Maybe I’m overcomplicating it. I’ll experiment with different things and just see what works and what doesn’t.