Error when deploying LXD VMS, MAAS 3.4.3 No host network to attach VM interfaces to

Users
1

Hello,
I am trying to get VM provisioning to work on a baremetal host but am running into the following error when trying to deploy VMs:
Pod unable to compose machine: Unable to compose machine because: Failed talking to pod: No host network to attach VM interfaces to

I couldn’t find any current documentation on how to setup the bridge network but this is what I have set up in the MAAS UI (first pic)

And my LXD setup (second pic)
Any tips here would be appreciated as I’ve been trying to get around this issue for weeks.

maas
maas2381×1234 222 KB

2

Resurrecting the dead here, but I’ve got the same issue. Simply deployed a machine with the KVM option. Afterwards, trying to create a VM with default settings results in the above mentioned error.

3

In my case it was picky about the DHCP server. I was using my own. Once I enabled MaaS’ DHCP server in the vlan, it started working.

not ideal because now i have 2 DHCP servers in one broadcast domain.

4

moved this to the “Users” category, where it will get more visibility.

5

not ideal because now i have 2 DHCP servers in one broadcast domain.

there will be dragons!

6

Why does the lxd stuff need DHCP? My ‘normal’ machines work fine with my own DHCP and some forwarding to the maas machine for the initial tftp bootstrap. Is the LXD functionality just more strict? Could we amend it to work without Maas’ own DHCP server?

Would be nice if maas could be a bit less opinionated on one’s infrastructure. It’s really not always feasible to do everything with maas’ DHCP server in a vlan.

7

It’s more simple than that: if you need VMs, use LXD directly. If you need bare metals, use MAAS.

If you are using the LXD DHCP server as well just disable it and design your network topology accordingly

8

@r00ta you mean advising against using the lxd functionality in MAAS for creating VMs in this case?

I think MAAS could benefit from another setting in a VLAN’s DHCP config, namely, explicitly setting an option signalling that there is an external DHCP server which is compatible with MAAS. In that case the logic in the code would run as normal without the error the topic-starter and I saw.

9

You should disable the LXD DHCP in the subnets that you use to PXE the VMs

10

Those LXD DHCP are not the problem, they are off already.

In my case I had to enable the MAAS dhcp before things started working. I never had a MAAS DHCP because in my case my lab router provides that already and normal bare metal machines provisioned fine with MAAS plus that existing non-MAAS dhcp server.

I’m hoping that MAAS can be more open to using an existing DHCP server in the case of LXD functionality.

11

I still don’t get what’s the ideal setup you’d like to have. Do you want to provision VMs without the MAAS DHCP server? What DHCP server would you use?

If for some weird reasons you don’t want to use the MAAS DHCP server you can use a container on the VM’s subnet to provide it and use MAAS as next-server

12

If for some weird reasons you don’t want to use the MAAS DHCP server you can use a container on the VM’s subnet to provide it and use MAAS as next-server

But the reason for this whole topic is that you can’t do that, because you lose the ease of MAAS-ui to be able to make virtual machines on your LXD instances. You get the error that the OP is showing in the screenshot.

13

Now it’s clear, thank you for clarifying.

There is some logic in MAAS that is matching subnets where you have DHCP enabled. This is because MAAS does not know if the external DHCP server is actually pointing to MAAS, so this needs some thinking as we might need the user’s input.

My suggestion would be to not use MAAS to compose VMs: this feature will be dropped in the
future (no ETA, but it will happen) because the general concept is

  • you want VMs => use LXD
  • you want metal => use MAAS