Getting two IPs - 10-lxc.yaml applies DHCP although 50-cloud-init.yaml is set to STATIC

I’m creating a container via the LXD api and setting the cloud-init options via user.network-config:

The works and the container picks up the static ip / dns settings specified. However the container also picks up a DHCP IP from my router. I’ve narrowed it down to 10-lxc.yaml which sets dhcp4: true.

If I set 10-lxc.yaml explicitly to false or remove the file, the expected behavior of getting only the static ip works.

Is this file supposed to be removed somehow or how is it also applying cloud-init settings if 50-cloud-init.yaml is being processed? Is it supposed to be ignored?

Container is running Ubuntu 18.04.3 LTS with cloud-init.

Thanks in advance for any help!

Contents of 10-lxc.yaml:

network:
  version: 2
  ethernets:
    eth0: {dhcp4: true}

Contents of 50-cloud-init.yaml (as generated by user.network-config:

network:
    version: 2
    ethernets:
        eth0:
            addresses:
            - 192.168.1.133/24
            gateway4: 192.168.1.254
            nameservers:
                addresses:
                - 1.1.1.1
                - 8.8.8.8

ip a outputs:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
67: eth0@if68: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:8f:b6:ea brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.133/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.125/24 brd 192.168.1.255 scope global secondary dynamic eth0
       valid_lft 85861sec preferred_lft 85861sec
    inet6 fe80::216:3eff:fe8f:b6ea/64 scope link 
       valid_lft forever preferred_lft forever
1 Like

What image did you use?

Description: Ubuntu bionic amd64 (20200123_07:42)
Architecture: x86_64
Fingerprint: 9a71a8cd25cb

I copied it to my local install via lxc image copy images:<finger print> local: --alias=<myalias> a while back (back in January I believe). I can’t seem to find the original image I copied it from based on the fingerprint unfortunately.

My containers are being spun up by the local copy.

1 Like

Just to make sure it wasn’t due to the old image, I tried the latest from images: with fingerprint 5f6884b0ebbb and same issue with 10-lxc.yaml.

Full details:
ubuntu/18.04/cloud (3 more) | 5f6884b0ebbb | yes | Ubuntu bionic amd64 (20200402_07:42) | x86_64 | CONTAINER | 105.18MB | Apr 2, 2020 at 12:00am (UTC)

Thank you again!

Ok, so yeah, cloud images really shouldn’t have the 10-lxc.yaml since cloud-init will be used to generate its own thing.

Probably just needs a tweak to our images. @monstermunchkin

Ok good to know and thank you for looking into that!

I’ve got a temporary fix in place now which is to write the following to 10-lxc.yaml:

network:
  version: 2
  ethernets:
    eth0: {dhcp4: false}

Side note: I initially set the contents of 10-lxc.yaml to be blank or just a comment, but that causes cloud-init to not setup the static IP in 50-cloud-init.yaml for some reason. Tried grep’ing the cloud-init.log / cloud-init-output.log to see why, but nothing stuck out (also not super familiar with the cloud-init process to be honest).

Regardless, my temp fix above works for now, thanks!

1 Like

Great post @Noah, thanks! Really helped ALOT on an issue with Orabuntu-LXC.

FWIW there is a way to override the “dhcp4: true” setting in 10-lxc.yaml (although I can’t image a use case). This was the band-aid I had been using until I saw this thread. So the band-aid was to put this entry in the dhcpd.conf file for the isc-dhcp-server service:

host “ContainerName” {
hardware ethernet 00:16:3e:8f:b6:ea;
deny booting;
}

which will block the DHCPOFFER and DHCPREQUEST with a message “booting denied.” Interface eth0 will continue to get a STATIC IP with no issues.

Making the change to 10-lxc.yaml seems a much preferable solution.