Documentation< Previous | Contents | Next >
The password can then be provided when the client registers r1 as a known remote. 5.6.2. Backing store
LXD supports several backing stores. The recommended backing store is ZFS, however this is not available on all platforms. Supported backing stores include:
• ext4: this is the default, and easiest to use. With an ext4 backing store, containers and images are simply stored as directories on the host filesystem. Launching new containers requires copying a whole filesystem, and 10 containers will take up 10 times as much space as one container.
• ZFS: if ZFS is supported on your architecture (amd64, arm64, or ppc64le), you can set LXD up to use it using 'lxd init'. If you already have a ZFS pool configured, you can tell LXD to use it by setting the zfs_pool_name configuration key:
lxc config set storage.zfs_pool_name lxd
With ZFS, launching a new container is fast because the filesystem starts as a copy on write clone of the images' filesystem. Note that unless the container is privileged (see below) LXD will need to change
ownership of all files before the container can start, however this is fast and change very little of the actual filesystem data.
• Btrfs: btrfs can be used with many of the same advantages as ZFS. To use BTRFS as a LXD backing store, simply mount a Btrfs filesystem under /var/lib/lxd. LXD will detect this and exploit the Btrfs subvolume feature whenever launching a new container or snapshotting a container.
• LVM: To use a LVM volume group called 'lxd', you may tell LXD to use that for containers and images using the command
lxc config set storage.lvm_vg_name lxd
When launching a new container, its rootfs will start as a lv clone. It is immediately mounted so that the file uids can be shifted, then unmounted. Container snapshots also are created as lv snapshots.