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

LXD
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:

[Match]
Name=lxdbr0

[Network]
DNS=10.121.179.1
Domains=~lxd

[Address]
Address=10.121.179.1/24
Gateway=10.121.179.1

(replace 10.121.179.1 with the address of your lxdbr0 bridge)

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

Step 3: reboot your machine.

Finished.

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

Thanks

3 Likes
2

Hi!

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

3

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

Thanks!

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…

5

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

6

Nice solution @karjala, neat and elegant.

Could you point me in the right direction for making it available clusterwide? (3 nodes in my case)

7

@simos I Would really appreciate (pretty sure I’m not the only one) if you would bless or otherwise explain why not to use this, cause it’s working fine on my (almost ready for production) setup…

8

Could you point me in the right direction for making it available clusterwide? (3 nodes in my case)

I don’t know anything about clusters.

9

It’s working for me, since the hosts are not part of the cluster’s DNS, just following the steps you suggested on each node makes DNS resolution available on them. Hope it doesn’t have any unintended consequences, I’ll report back here if I get in any trouble…

10

In Ubuntu 19.10 Desktop edition (snap LXD), my solution seems to have stopped working. The problem I saw on two such systems, was that the launched containers did not acquire IPv4 and IPv6 address.

On the contrary, simos’s solution seems to work fine on the 19.04 Desktops (snap LXD).

11

Simos’s solution seems to work only until laptop enters sleep mode. Then, after it wakes up, you need to re-do some of Simos’s steps to get DNS working as expected again.

12

This has been working brilliantly for me, for months. But I installed Ubuntu focal (development), and now my containers have no IPv4 addresses. Trying sudo systemctl status systemd-networkd, I see a warning in the log entries:

● systemd-networkd.service - Network Service
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2020-04-06 08:43:18 CDT; 2s ago
TriggeredBy: ● systemd-networkd.socket
[...]
Apr 06 08:43:18 t460 systemd[1]: Starting Network Service...
Apr 06 08:43:18 t460 systemd-networkd[23909]:
    /etc/systemd/network/lxd.network:10:
    Unknown key name 'Gateway' in section 'Address', ignoring.

Anyone got ideas?

13

I think the "Unknown key name “Gateway” is not relevant. Folks with a working system also see that warning.

14

User Bram posted a comment at my tutorial at


See the last comment.

He explains that the reason why sometimes my tutorial does not work, has to do with a race condition in systemd.
If someone else can also give it a try, I can update my tutorial. Works for me.

1 Like
15

Hi @tartley. I had the exact same problem a few months ago (without install focal) and then searched a lot on google for my problem and found a solution, which if I remember well was a single lxd command which I didn’t write down unfortunately but it fixed the problem permanently and without exceptions.

Let me check my lxd config and see if I see anything interesting there… I will be with you shortly.

16

@tartley, no, sorry, I don’t see anything there.

17

Probably this one?

$ echo -e "auth-zone=lxd\ndns-loop-detect" | lxc network set lxdbr0 raw.dnsmasq -
18

Hello, for anyone using the solution with networkd lxd.network be sure to add IgnoreCarrierLoss=yes
below [Network] this will make the lxdbr0 bridge to not lose the IP

19

My problems seemed to stem from two sources:

a) At some point(*) my lxd bridge got a different IP address, so it no longer matched the IP address in the /etc/systemd/network/lxd.network file I’d created.

b) At some point(*) things stopped working, or maybe only worked intermittently, until I got rid of the lxd bridge’s IPv6 address:

lxc network set lxdbr0 ipv6.address none

I read a random blog post somewhere saying that NetworkManager had some problem with an IPv6 there, causing it to fail to complete assigning containers IPv4 addresses.

With the above two things fixed, this has been working perfectly for me for months now.

(*) maybe upon upgrading to a pre-release version of Focal

20

This solution worked for me initially, but after a few days and reboots resolution started failing.

My containers have ip addresses, but attempting to resolve them produces

$ systemd-resolve -4 ros2-dev.lxd
ros2-dev.lxd: resolve call failed: All attempts to contact name servers or networks failed

Changing lxd.network to

[Match]
Name=lxdbr0

[Network]
Address=10.121.221.1/24
DNS=10.121.221.1
Domains=~lxd
IgnoreCarrierLoss=yes

fixed it, but I’m not sure the [Address] block was the cause