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
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
(initialize)=
# How to initialize LXD
Before you can create a LXD instance, you must configure and initialize LXD.
## Interactive configuration
Run the following command to start the interactive configuration process:
lxd init
```{note}
For simple configurations, you can run this command as a normal user.
However, some more advanced operations during the initialization process (for example, joining an existing cluster) require root privileges.
In this case, run the command with `sudo` or as root.
```
The tool asks a series of questions to determine the required configuration.
The questions are dynamically adapted to the answers that you give.
They cover the following areas:
Clustering (see {ref}`exp-clustering` and {ref}`cluster-form`)
: A cluster combines several LXD servers.
The cluster members share the same distributed database and can be managed uniformly using the LXD client (`lxc`) or the REST API.
The default answer is `no`, which means clustering is not enabled.
If you answer `yes`, you can either connect to an existing cluster or create one.
MAAS support (see [`maas.io`](https://maas.io/) and [MAAS - Setting up LXD for VMs](https://maas.io/docs/setting-up-lxd-for-vms))
: MAAS is an open-source tool that lets you build a data center from bare-metal servers.
The default answer is `no`, which means MAAS support is not enabled.
If you answer `yes`, you can connect to an existing MAAS server and specify the `name`, `URL` and `API key`.
Networking (see {ref}`networks` and {ref}`Network devices <devices-nic>`)
: Provides network access for the instances.
You can let LXD create a new bridge (recommended) or use an existing network bridge or interface.
You can create additional bridges and assign them to instances later.
Storage pools (see {ref}`exp-storage` and {ref}`storage-drivers`)
: Instances (and other data) are stored in storage pools.
For testing purposes, you can create a loop-backed storage pool.
For production use, however, you should use an empty partition (or full disk) instead of loop-backed storage (because loop-backed pools are slower and their size can't be reduced).
The recommended backends are `zfs` and `btrfs`.
You can create additional storage pools later.
Remote access (see {ref}`security_remote_access` and {ref}`authentication`)
: Allows remote access to the server over the network.
The default answer is `no`, which means remote access is not allowed.
If you answer `yes`, you can connect to the server over the network.
You can choose to add client certificates to the server (manually or through tokens, the recommended way) or set a trust password.
Automatic image update (see {ref}`about-images`)
: You can download images from image servers.
In this case, images can be updated automatically.
The default answer is `yes`, which means that LXD will update the downloaded images regularly.
YAML `lxd init` preseed (see {ref}`initialize-preseed`)
: If you answer `yes`, the command displays a summary of your chosen configuration options in the terminal.
### Minimal setup
To create a minimal setup with default options, you can skip the configuration steps by adding the `--minimal` flag to the `lxd init` command:
lxd init --minimal
```{note}
The minimal setup provides a basic configuration, but the configuration is not optimized for speed or functionality.
Especially the [`dir` storage driver](storage-dir), which is used by default, is slower than other drivers and doesn't provide fast snapshots, fast copy/launch, quotas and optimized backups.
If you want to use an optimized setup, go through the interactive configuration process instead.
```
(initialize-preseed)=
## Non-interactive configuration
The `lxd init` command supports a `--preseed` command line flag that makes it possible to fully configure the LXD daemon settings, storage pools, network devices and profiles, in a non-interactive way through a preseed YAML file.
For example, starting from a brand new LXD installation, you could configure LXD with the following command:
```bash
cat <<EOF | lxd init --preseed
config:
core.https_address: 192.0.2.1:9999
images.auto_update_interval: 15
networks:
- name: lxdbr0
type: bridge
config:
ipv4.address: auto
ipv6.address: none
EOF
```
This preseed configuration initializes the LXD daemon to listen for HTTPS connections on port 9999 of the 192.0.2.1 address, to automatically update images every 15 hours and to create a network bridge device named `lxdbr0`, which gets assigned an IPv4 address automatically.
### Re-configuring an existing LXD installation
If you are configuring a new LXD installation, the preseed command applies the configuration as specified (as long as the given YAML contains valid keys and values).
There is no existing state that might conflict with the specified configuration.
However, if you are re-configuring an existing LXD installation using the preseed command, the provided YAML configuration might conflict with the existing configuration.
To avoid such conflicts, the following rules are in place:
- The provided YAML configuration overwrites existing entities.
This means that if you are re-configuring an existing entity, you must provide the full configuration for the entity and not just the different keys.
- If the provided YAML configuration contains entities that do not exist, they are created.
This is the same behavior as for a `PUT` request in the {doc}`../rest-api`.
#### Rollback
If some parts of the new configuration conflict with the existing state (for example, they try to change the driver of a storage pool from `dir` to `zfs`), the preseed command fails and automatically attempts to roll back any changes that were applied so far.
For example, it deletes entities that were created by the new configuration and reverts overwritten entities back to their original state.
Failure modes when overwriting entities are the same as for the `PUT` requests in the {doc}`../rest-api`.
```{note}
The rollback process might potentially fail, although rarely (typically due to backend bugs or limitations).
You should therefore be careful when trying to reconfigure a LXD daemon via preseed.
```
### Default profile
Unlike the interactive initialization mode, the `lxd init --preseed` command does not modify the default profile, unless you explicitly express that in the provided YAML payload.
For instance, you will typically want to attach a root disk device and a network interface to your default profile.
See the following section for an example.
### Configuration format
The supported keys and values of the various entities are the same as the ones documented in the {doc}`../rest-api`, but converted to YAML for convenience.
However, you can also use JSON, since YAML is a superset of JSON.
The following snippet gives an example of a preseed payload that contains most of the possible configurations.
You can use it as a template for your own preseed file and add, change or remove what you need:
```yaml
# Daemon settings
config:
core.https_address: 192.0.2.1:9999
core.trust_password: sekret
images.auto_update_interval: 6
# Storage pools
storage_pools:
- name: data
driver: zfs
config:
source: my-zfs-pool/my-zfs-dataset
# Network devices
networks:
- name: lxd-my-bridge
type: bridge
config:
ipv4.address: auto
ipv6.address: none
# Profiles
profiles:
- name: default
devices:
root:
path: /
pool: data
type: disk
- name: test-profile
description: "Test profile"
config:
limits.memory: 2GB
devices:
test0:
name: test0
nictype: bridged
parent: lxd-my-bridge
type: nic
```
|
