Hello, I’ve installed maas 2.8 via snap in LXD, and am using the default lxdbr0 bridge on a 10.53.X.Y default network which is VLAN untagged, and maas is set to serve DHCP/DNS/PXE on it.
When I add a QEMU VM configured with an empty disk and a NIC attached to the same bridge (lxdbr0), configured to PXE boot it does PXE boot the commissioning image, but fails near the end with:
raise DataSourceNotFoundException(msg)
cloudinit.sources.DataSourceNotFoundException:
Did not find any data source, searched classes: ()
[FAILED] Failed to start Execute cloud user/final scripts.
This seems to occur regardless of commissioning image used.
I found some similar errors reported by other users in the past with root causes of not being able to communicate with the region controller, but in this case, maas is initialized as rack+region with the test-db.
I’ve spun up a separate QEMU ubuntu 20.04 VM and attached it to only the lxdbr0 bridge in the same manner as the failing PXE commissioning VM to check that networking (MaaS DNS, DHCP, etc) is working properly and everything seems to be ok. I’m not seeing anything that jumps out at me as a cause of the problem in the various maas common snap logs.
Does anyone have any pointers on how to debug this?
Or is this maybe just an expectation problem on my part – maybe this just won’t work with a QEMU VM for some reason even though it PXE boots the commissioning image just fine? I was hoping this would work as it’s an easy at home test setup to trial the software.
Thanks @billwear. So I did track the source of this problem down.
I installed MaaS within LXD per the docs here: link.
In that installation procedure, the example given uses the default lxdbr0 bridge which is managed by LXD.
The managed lxdbr0 bridge automatically employs dnsmasq. During container creation I named the LXD container “maas” (also per the docs), and so from within the container, and on the container network from test machines, dig maas +short was resolving maas, but it was being resolved by dnsmasq for the LXD managed bridge rather than maas DNS itself where the full fqdn was maas.lxd rather than maas.maas.
I had to stop using the managed lxdbr0 bridge altogether to get maas DNS resolving properly. I also found this post helpful to migrate away from the lxdbr0 bridge and onto a non-managed bridge setup from within the host OS: https://discuss.linuxcontainers.org/t/lxd-via-snapd-disable-dnsmasq/450/2
If this issue and the other one I ran into regarding a failed maas install on LXD (link) were mentioned on the LXD install docs page (link), it would have saved me several hours of troubleshooting. It would probably save other LXD newbies substantial time too, so hopefully the docs there can get a minor update.
@johnny101, i updated the document – but it looked like the profile name was maas, not the container name. i probably missed something; help me out here?
Hi Bill – you’re right, in the docs the profile name is maas and the container name is bionic-maas. Sorry, I misread the command line in the docs this morning when writing the response above.
I think the problem still stands with the conflict, regardless of what the container is named, as I had other DNS names added to maas DNS that had no conflict with LXD container names, and they were not being served by maas DNS either due to dnsmasq.
thanks, @johnny101. so based on your concern, does the current page (as i’ve just updated it) read well enough, or do i need to alter it to be more clear? feel free to be brutal!
Hi @billwear, I would suggest something like the following. Perhaps someone more knowledgeable with LXD networking or other users testing a similar setup can improve it further. I don’t know if lxdbr0 dnsmasq conflicts with maas DNS in all setups, but it did seem to in my case. At the very least, though, this does provide a user who is trying MaaS with LXD and snap some debugging ideas and possible solutions:
The managed lxdbr0 bridge – recommended below – automatically employs dnsmasq. If maas DNS does not appear to be working post-install, it may be due to a conflict with dnsmasq. A non-functioning maas DNS service may result in errors such as “Did not find any data source” during machine enlistment. One solution is to migrate the LXD container to use an unmanaged bridge. 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.
@johnny101, that’s an excellent way to generalize what you experienced! if you don’t mind, i’ll use your version for now, and let some LXD networking experts know to have a look. thanks for contributing.
