LXD: Migrate Ubuntu 20.04 container from MACVLAN to routed

LXD
#1

Greetings,

I have an installation with LXD 5.9 and a set of ubuntu-minimal 20.04 containers that are all configured to have an eth0 as a MACVLAN from the host’s main ethernet

I need to migrate from MACVLAN to routed as I need to move the host to work over WiFi rather than ethernet for some time, and MACVLAN doesn’t seem to be working over WiFi

Following multiple discussions on this forum I managed to figure out a more-or-less working procedure, but I’m struggling with DNS settings on the container.

The procedure is as follows:

  1. Create a new profile for the specific IP
config:
  user.network-config: |
    version: 2
    ethernets:
        eth0:
            addresses:
            - 10.100.160.50/32
            nameservers:
                addresses:
                - 10.100.160.1
            routes:
            -   to: 0.0.0.0/0
                via: 169.254.0.1
                on-link: true
description: ""
devices:
  eth0:
    ipv4.address: 10.100.160.50
    name: eth0
    nictype: routed
    parent: enp1s0
    type: nic
name: routed_50
  1. Comment everything in the container’s /etc/netplan/50-cloud-init.yaml
  2. Restart container

After restarting the container seems to be able to reach the DGW at 10.100.160.1, ping available hosts on the lan but fails to resolve any host names. If I edit the /etc/resolve.conf and point it to my DGW instead of 127.0.0.53, the container starts resolving.

I found a similar problem from @nick_knutov and his solution of running systemd-resolve in the container appears to be working:

systemd-resolve --set-dns=10.100.160.1 --set-llmnr=yes --set-mdns=no --set-dnssec=no --interface=eth0

But unfortunately it doesn’t survive reboots or container restarts
Is there a way to make the DNS changes permanent?

P.S. It is quite possible that the problem is related to the cloud-init not working properly for ubuntu-minimal 20.04 images, that is still not resolved…

#2

Sounds like cloud-init isn’t applying the DNS nameserver 10.100.160.1 you specified.
What does resolvectl status show?
Does this work with the LXD built images, such as images:ubuntu/focal/cloud?

#3

After a restart of the container I can ping local IPs. resolvectl reports an “empty” config:

root@focaltest:~# resolvectl status
Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 49 (eth0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no

It seems that cloud init was mostly ignored as netplan get show absolutely nothing:

root@focaltest:~# netplan get
root@focaltest:~#

I’ve spawned a images:ubuntu/focal/cloud container, applied my default, my cloud_init and the mentioned routed profiles and it worked like a charm. netplan was reporting the correct config, resolvectl status too and the container was able to resolve hosts.

It seems that my problem is related to the broken cloud_init functionality on the ubuntu-minimal containers and I wonder if there’s a way to notify the maintainers of ubuntu-minimal of the problems with focal images…

#4

@stgraber @sdeziel do you know where to report issues with official Ubuntu cloud images?

Thanks

#5

https://cloud-images.ubuntu.com/ suggests to report bugs via OpenID transaction in progress

1 Like
#6

Opened the bug as suggested
Solution to the case was to “user.user-data:” instead of “cloud-init.user-data:” in the config statement of the JSON. Verified with 18.04-minimal