Install with LXD

LXD is a manager for Linux-based containers (LXC), offering a user experience similar to virtual machines without the same overheads.

Using LXD to install MAAS into containers is a good choice for users who want to test MAAS, or who may want to continue leveraging an existing container architecture or policy.

Quick questions you may have:

Some networking traps

The managed lxdbr0 bridge – recommended below – automatically employs dnsmasq. If you name the LXD container “maas”, you can get into a condition where “maas” is being resolved by dnsmasq for the LXD managed bridge rather than maas DNS itself, where the full fqdn is maas.lxd rather than maas.maas. Check this post for details.

Also, you may have to broaden the default root user subuid mapping to include the snap_daemon user. See this post for details and instructions.

Install with LXD (20.04)

Installing LXD for use with MAAS is quite simple:

snap install lxd
lxd init

If you expect to use multiple networks in your MAAS container (for example, libvirt KVMs), you’ll want to take the following steps:

lxc profile copy default maas-profile
lxc profile device set maas-profile eth0 network lxdbr0

From here, you can launch your container and install MAAS in the normal way for your chosen version, adding the -p maas-profile only if you created a special profile for MAAS networking:

lxc launch --profile maas-profile ubuntu:20.04 focal-maas
lxc exec focal-maas bash

Then, proceed with a normal MAAS install in a container.

Install with LXD (16.04/18.04)

MAAS running with LXD has the following requirements:

  • a network bridge on the LXD host (e.g. lxdbr0)
  • LXD and ZFS
  • a container profile

Install LXD and ZFS

Begin by installing LXD and ZFS:

sudo apt install lxd zfsutils-linux
sudo modprobe zfs
sudo lxd init

The sudo lxd init command will trigger a series of configuration questions. Except in the case where the randomly chosen subnet may conflict with an existing one in your local environment, all questions can be answered with their default values.

The bridge network is configured via a second round of questions and is named lxdbr0 by default.

Create a LXC profile for MAAS

First create a container profile by making use of the ‘default’ profile:

lxc profile copy default maas-profile

Second, bind the network interface inside the container (eth0) to the bridge on the physical host (lxdbr0):

lxc profile device set maas-profile eth0 parent lxdbr0

Thirdly, the maas container profile needs to be edited to include a specific set of privileges. Enter the following to open the profile in your editor of choice:

lxc profile edit maas-profile

And replace the {} after config with the following (excluding config:):

config:
  raw.lxc: |-
    lxc.cgroup.devices.allow = c 10:237 rwm
    lxc.apparmor.profile = unconfined
    lxc.cgroup.devices.allow = b 7:* rwm
  security.privileged: "true"

The final step adds the 8 necessary loop devices to LXC:

for i in `seq 0 7`; do lxc profile device add maas-profile loop$i unix-block path=/dev/loop$i; done

When correctly configured, the above command outputs Device loop0 added to maas-profile for each loop device.

Launch and access the LXD container

Launch the LXD container:

lxc launch -p maas-profile ubuntu:20.04 focal-maas

Once the container is running, it can be accessed with:

lxc exec focal-maas bash

Then, proceed with a normal MAAS install in a container.

Was this process tested? I went thru line-by-line, and got stuck installing MaaS via Snap due to udev issues.

root@bionic-maas:~# snap install maas --channel=2.7
2020-06-26T19:22:11Z INFO Waiting for restart...
error: cannot perform the following tasks:
- Setup snap "maas" (6633) security profiles (cannot setup udev for snap "maas": cannot reload udev rules: exit status 2
udev output:
)
- Setup snap "maas" (6633) security profiles (cannot reload udev rules: exit status 2
udev output:
)
- Setup snap "maas" (6633) security profiles for auto-connections (cannot reload udev rules: exit status 2
udev output:
)
root@bionic-maas:~# service udev reload
 * udev does not support containers, not started
root@bionic-maas:~# service udev start
root@bionic-maas:~# service udev reload
 * udev does not support containers, not started
root@bionic-maas:~# service udev status
● systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor preset: enabled)
   Active: inactive (dead)
Condition: start condition failed at Fri 2020-06-26 19:25:54 UTC; 3s ago
           └─ ConditionPathIsReadWrite=/sys was not met
     Docs: man:systemd-udevd.service(8)
           man:udev(7)

If you are here because you’re seeing udev install issues with snap install maas then this is how you can resolve it on your container…

Prior to deploying your container, add this config to your profile:

config:
  raw.lxc: |-
    lxc.mount.auto=sys:rw
    lxc.cgroup.devices.allow = c 10:237 rwm
    lxc.apparmor.profile = unconfined
    lxc.cgroup.devices.allow = b 7:* rwm
  security.privileged: "true"

OR

Apply it to your already running container:

lxc config set bionic-maas raw.lxc "lxc.mount.auto=sys:rw"

Note: I don’t know what the security ramifications of lxc.mount.auto=sys:rw are, but it fixed it for me.

1 Like

Might also want to document something about this problem that I ran into with LXD and maas snap install which required a time consuming dive into LXD operations details to resolve: