MAAS Show and Tell: Improvements to LXD with MAAS

Today, Alberto is going to tell us about MAAS improvements we’ve made with respect to LXD. Please remember that you can post comments and questions below. Enjoy the video, and the summary write-up which follows it:

For this show and tell, we want to showcase some of the ongoing work for the next MAAS release. We’re working on improving MAAS support for LXD VMs.

A quick history of VM hosts in MAAS

Initially, in the first implementation of VM hosts for MAAS (called “pods”), VM hosts were created and managed through libvirt. At that point, the idea was to deploy a machine in MAAS and enlist it as a VM host. From there, you could compose VMs in MAAS on that host. It was scoped so that MAAS would be the only consumer of that VM host, hence MAAS would manage all the VMs there.

The first implementation of LXD VM hosts was similar: same concept and mechanics, just using LXD as a back-end for managing the virtual machines. In the current MAAS release, we want to improve on that and make it easier to use MAAS to manage and deploy machines on existing LXD hosts. We’re doing this by implementing support (in MAAS) for LXD projects.

Introducing LXD projects

If you’re not familiar with them, LXD projects are basically a way to group resources (virtual machines, containers, images, networks, profiles, …). In MAAS, you can work in the context of a specific project, and only see a subset of the resources that are present on the LXD instance.

Suppose we have a LXD, with just one container running MAAS, like this:


This is what you see when you don’t specify a project, because LXD uses the concept of a default project. If you explicitly list the projects, you can see that what we were looking at is, indeed, the default project – but there are two other projects:


If we list the machines in one of them, we can see there’s a virtual machine in there:


and also in the other one:


Supporting projects in MAAS

We are currently implementing LXD project support in MAAS. Our aim is to give you tools to scope MAAS to a given project, so that you can manage a subset of VMs, without the distraction of other VMs or containers in your LXD instance. Specifically, we’ve added the to specify a project when creating a LXD VM host, and limit MAAS views and actions to that project.

For example, you will be able to do things like:

maas $PROFILE vm-hosts create type=lxd name=$VM_HOST_NAME power_address=$LXD_POWER_ADDRESS project=$PROJECT_NAME

This will create a VM host, as we can see by using:

maas $PROFILE virtual-machines read | jq -S

In the case of our example MAAS, this returns JSON something like this:


We can see that the VMs listed are in different projects. Only one of these is associated with a MAAS machine (the VM in project1). You can tell this by looking at the machine_id – it’s 12 for the first VM, and null for the second:


MAAS only creates machines and commissions them in the specific project given in the create command.

If we look at the two projects with lxc list --project $PROJECT_NAME, you’ll see that the first has been started because it’s being commissioned by MAAS. The other one hasn’t been touched, because it’s in a different project:

To reiterate, MAAS can see all the resources that are present in LXD, but it only acts on machines in the project you specify. You can test this with maas $PROFILE machines read pod=$VM_NAME | jq -S '.[] | [.system_id, .hostname]', with $VM_NAMEmatching the VM host you created forproject1`:

You’ll see that only one machine created by MAAS, with the hostname of the VM that was in project1.

Composition scoped to a project

We can also compose a machine, like this (for example):

maas $PROFILE vm-host compose $VM_HOST_ID hostname=vm3 cores=2 memory=4096

Again, using our example MAAS, that command might go like this:


This has created a new machine in MAAS. If we look at those virtual machines, we’ll see a new VM in project1 as well, because MAAS will only manage machines in the project that has been configured:

or viewed from LXD:


Improvements to the VM host removal process

Previously, when you removed a VM host from MAAS, the program tried to make a distinction between the VMs it composed and VMs that were already there. We’re changing that behaviour: By default, in the new version, MAAS will keep all the machines – unless you specifically tell it to remove them. This project would be managed by MAAS, so you can clean up on your own, with a command like:

maas $PROFILE vm-host delete $VM_HOST_ID decompose=true

On our example MAAS, it would look something like this:


You can verify with LXD that both virtual machines are gone:


Creating projects with MAAS

When you register your LXD in the API, you can also specify a new project that you want to use with MAAS, and MAAS will create it for you:

maas $PROFILE vm-hosts create type=lxd name=$VM_HOST_NAME power_address=$POWER_ADDRESS project=$PROJECT_NAME

which we’d execute like this in our example MAAS:

You can verify the result with lxc project list:

You can verify that MAAS created it with the command lxc project show new-project:


Note the highlighted description above.

In the UI, when you are managing a VM host, you will be able to choose whether to keep the VM hosts as well, though that is not yet implemented.


I’m following any LXD improvements eagerly, however I find the audio on this clip very difficult to understand, room acoustics be damned! Is there a writeup anywhere on what’s new?

@seffyroff, sorry about the audio quality. I’ll see if I can’t get you a writeup shortly.

@seffyroff, see the write-up I’ve added above. does that help any?

1 Like

Thanks So much @billwear!

I shall devour this today.

1 Like

Looks really promising. I look forward to replacing my virsh-controlled VM host rigging with LXD.

Is there any intent to additionally support containers in addition to VMs through LXD in MAAS, or is it generally accepted that Juju is the proper way to do that?