Incus doesn't show IP addresses in Pop!_OS 22.04 LTS

Incus
1

This has been a nuisance for a while, but its causing me problems testing Terraform as the instances are always “tainted” because it fails to get an IP address. Most issues seem to be firewall, but in this case, the containers are getting both v4 and v6 addresses and networking seems normal. I’ve got a couple different machines with Pop 22.04 with the same issue, and other machines running Ubuntu Server 22.04 that report IP addresses normally. The other major difference is the network bridge configurations.

I’d like to understand how does Incus obtain the container IP addresses? Why is it failing to do so?

Thank you.

Starting from the top: “incus launch images:ubuntu/22.04 alpha”

When I run incus list, IPV4 and IPV6 are blank

+-------+---------+------+------+-----------+-----------+
| NAME  |  STATE  | IPV4 | IPV6 |   TYPE    | SNAPSHOTS |
+-------+---------+------+------+-----------+-----------+
| alpha | RUNNING |      |      | CONTAINER | 0         |
+-------+---------+------+------+-----------+-----------+

The IPv6 IP does show here, but no IPv4

incus info alpha

Name: alpha
Status: RUNNING
Type: container
Architecture: x86_64
PID: 92795
Created: 2024/12/18 07:28 EST
Last Used: 2024/12/18 07:28 EST
Started: 2024/12/18 07:28 EST

Resources:
  Processes: 13
  CPU usage:
    CPU usage (in seconds): 0
  Memory usage:
    Memory (current): 37.91MiB
  Network usage:
    eth0:
      Type: broadcast
      State: UP
      Host interface: veth7173171f
      MAC address: 00:16:3e:1d:09:20
      MTU: 1500
      Bytes received: 808B
      Bytes sent: 1.88kB
      Packets received: 4
      Packets sent: 18
      IP addresses:
        inet6: fe80::216:3eff:fe1d:920/64 (link)
    lo:
      Type: loopback
      State: UP
      MTU: 65536
      Bytes received: 0B
      Bytes sent: 0B
      Packets received: 0
      Packets sent: 0
      IP addresses:
        inet:  127.0.0.1/8 (local)
        inet6: ::1/128 (local)

incus exec alpha ip a

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
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:1d:09:20 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.222.172/24 metric 100 brd 10.0.222.255 scope global dynamic eth0
       valid_lft 3317sec preferred_lft 3317sec
    inet6 fe80::216:3eff:fe1d:920/64 scope link 
       valid_lft forever preferred_lft forever

From the container, I can reach the internet fine, updating packages, ping google, etc.

incus profile show default

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
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:1d:09:20 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.222.172/24 metric 100 brd 10.0.222.255 scope global dynamic eth0
       valid_lft 3317sec preferred_lft 3317sec
    inet6 fe80::216:3eff:fe1d:920/64 scope link 
       valid_lft forever preferred_lft forever

incus network show incusbr0

config:
  ipv4.address: 10.0.222.1/24
  ipv4.nat: "true"
  ipv6.address: none
description: ""
name: incusbr0
type: bridge
used_by:
- /1.0/instances/alpha
- /1.0/instances/draco?project=helu.ca
- /1.0/instances/iris?project=helu.ca
- /1.0/profiles/default
- /1.0/profiles/sandbox
managed: true
status: Created
locations:
- none
project: default
2

When a container is launched, the container runtime starts up and makes a request for network configuration (if the image has been configured to do so). Externally, in Incus, you have specified which network interfaces will be provided to the container. The default configuration in Incus is to provide the incusbr0 managed bridge, and configure a DHCP service with an instance of dnsmasq to provide network configuration.

If your containers do not get any network configuration through DHCP from the dnsmasq service (offered by Incus), then the most common root of the problem, is a firewall that blocks those network configuration requests/responses.

Have a look in there, and report back.

1 Like
3

It can take a few moments to a minute after starting a container for the IP address to be assigned to the network card from the DHCP server.

Does your problem go away after a while or does it persist even after the IP address is assigned?

4

Another thought I had that could help with your Tofu code is to ignore the attribute that is tainting your instances.

5

There was a kernel bug a while back which would cause incus list to not show addresses.
So you may want to make sure that all package updates are applied on your system and reboot to make sure you’re on an up to date kernel.

6

Thanks. It turns out TF isn’t fussed about the IP address, rather it is timing out waiting for the network. Setting wait_for_network to false works.

1 Like