A way to resolve container.lxd from host, in all cases


(Alexander Karelas) #1

A common problem:
You can’t resolve the hostname container.lxd (if you have a container named ‘container’) when on the host (using Ubuntu 18.04+).
@simos has proposed a solution in this blog post, however it doesn’t work perfectly in all cases. For example: I think that if lxd is installed with snap, and the host is Ubuntu Desktop, it will not work after a reboot. Or, as was the case on my ubuntu cloud vps, when I applied simos’s proposed solution, I couldn’t resolve any non-lxd names from inside a container anymore. I.e. host news.com would just fail, from inside the container.

Now I think I found a solution that works in all environments (Desktop, Server, Snap & Apt), which can be applied instead of simos’s blog post:

Step1: create a new file named /etc/systemd/network/lxd.network with these contents:




(replace with the address of your lxdbr0 bridge)

Step 2: do this: sudo systemctl enable systemd-networkd

Step 3: reboot your machine.


@simos, does this seem like a perfectly good solution?




I am not able to test at the moment. I will probably be able to try during the week.

(Alexander Karelas) #3

Hi, @simos. Did you have a chance to look at my solution?


(Zipi Zap Zap) #4

Great work - that can solve it, with the installation of systemd-network.

I’ll reply from memory (so might get some details mistaken), about what I’ve read some weeks ago about this.
Ubuntu 18.04 (and even some 17.xx before) started having the systemd-network (a network-manager) and systemd-resolved (dns-manager). Also, it introduced another sw - the netplan - which is like a simpler-abstraction on top of whatever-network-manager-there-is-bellow (currently supporting systemd-network and network-manager, but can be extended by others).
So the idea is that netplan will use the available-network-manager-that-exists (systemd-network by default in 18.04) and on the other hand, you can add the *.network files to configure new interfaces at systemd-network. Then systemd-network will internally use the DBUS interface to send updates to the DNS config into systemd-resolve, and that’s how the dns gets configured for the whole system.

However, systemd-network is not mandatory, its optional - so other alternatives of network-configuration can be used (and probably should for a while, untill all these new stacks get tried&tested&mature enough to be trusted) like the old interface scripts, or dhcpclient3 or others.
My take on all this was that systemd is trying to take control of many different things, but that is still a bit green - the docs are not all clear, features already documented are not all available, bugs seem to exist… It will certainly be great when all is polished by time and properly “ironed-out” - but at this point, it seems to be still difficult to understand clearly what is happening in all the different stacks…

In resume: if there is nothing against systemd-network, then that will work and (at least this part) will be stable into the future. However it might be interesting to understand that there are other networking-features that systemd-network might still not have in place completely, to replace the existing alternatives.

This was my memory-impressions - please take me to the ground wherever I’m incorrect - really hope things to be much better that what I though of them :slight_smile: Its just that it feels uncomfortable to me that all these system-critical-tools are all being revamped with such hurry and confusion, where before there was no problem…

(Alexander Karelas) #5

@ZipiZap_Zap, my knowledge of Linux networking is very poor, and I am not able to answer to your message.