summaryrefslogtreecommitdiff
path: root/doc/rtd/topics/datasources/lxd.rst
blob: 3b523d504a8102945842a006f1dbcad92af60d36 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
.. _datasource_lxd:

LXD
===

The data source ``LXD`` allows the user to provide custom user-data,
vendor-data, meta-data and network-config to the instance without running
a network service (or even without having a network at all). This datasource
performs HTTP GETs against the `LXD socket device`_ which is provided to each
running LXD container and VM as ``/dev/lxd/sock`` and represents all
instance-metadata as versioned HTTP routes such as:

  - 1.0/meta-data
  - 1.0/config/user.meta-data
  - 1.0/config/user.vendor-data
  - 1.0/config/user.user-data
  - 1.0/config/user.<any-custom-key>

The LXD socket device ``/dev/lxd/sock`` is only present on containers and VMs
when the instance configuration has ``security.devlxd=true`` (default).
Disabling ``security.devlxd`` configuration setting at initial launch will
ensure that cloud-init uses the :ref:`datasource_nocloud` datasource.
Disabling ``security.devlxd`` over the life of the container will result in
warnings from cloud-init and cloud-init will keep the originally detected LXD
datasource.

The LXD datasource is detected as viable by ``ds-identify`` during systemd
generator time when either ``/dev/lxd/sock`` exists or
``/sys/class/dmi/id/board_name`` matches "LXD".

The LXD datasource provides cloud-init the ability to react to meta-data,
vendor-data, user-data and network-config changes and render the updated
configuration across a system reboot.

To modify what meta-data, vendor-data or user-data are provided to the
launched container, use either LXD profiles or
``lxc launch ... -c <key>="<value>"`` at initial container launch setting one
of the following keys:

 - user.meta-data: YAML metadata which will be appended to base meta-data
 - user.vendor-data: YAML which overrides any meta-data values
 - user.network-config: YAML representing either :ref:`network_config_v1` or
   :ref:`network_config_v2` format
 - user.user-data: YAML which takes preference and overrides both meta-data
   and vendor-data values
 - user.any-key: Custom user configuration key and value pairs can be passed to
   cloud-init. Those keys/values will be present in instance-data which can be
   used by both `#template: jinja` #cloud-config templates and
   the `cloud-init query` command.

Note: LXD version 4.22 introduced a new scope of config keys prefaced by
``cloud-init.`` which are preferred above the related ``user.*`` keys:

 - cloud-init.meta-data
 - cloud-init.vendor-data
 - cloud-init.network-config
 - cloud-init.user-data


By default, network configuration from this datasource will be:

.. code:: yaml

  version: 1
  config:
      - type: physical
        name: eth0
        subnets:
            - type: dhcp
              control: auto

This datasource is intended to replace :ref:`datasource_nocloud`
datasource for LXD instances with a more direct support for LXD APIs instead
of static NoCloud seed files.

.. _LXD socket device: https://linuxcontainers.org/lxd/docs/master/dev-lxd
.. vi: textwidth=79

Hotplug
-------

Network hotplug functionality is supported for the LXD datasource as described
in the :ref:`events` documentation. As hotplug functionality relies on the
cloud provided network metadata, the LXD datasource will only meaningfully
react to a hotplug event if it has the configuration necessary to respond to
the change has been provided to LXD. Practically, this means that
even with hotplug enabled, **the default behavior for adding a new virtual
NIC will result no change**.

To update the configuration to be used by hotplug, first pass the network
configuration via the ``cloud-init.network-config`` (or
``user.network-config`` on older versions).

For example, given an LXD instance named ``my-lxd`` with hotplug enabled and
an LXD bridge named ``my-bridge``, the following will allow for additional
DHCP configuration of ``eth1``:

.. code-block:: shell-session

    $ cat /tmp/cloud-network-config.yaml
    version: 2
    ethernets:
        eth0:
            dhcp4: true
        eth1:
            dhcp4: true

    $ lxc config set my-lxd cloud-init.network-config="$(cat /tmp/cloud-network-config.yaml)"
    $ lxc config device add my-lxd eth1 nic name=eth1 nictype=bridged parent=my-bridge
    Device eth1 added to my-lxd