IPv4 not coming up on one cluster host node

Incus
1

Incus beginner here desperately throwing stuff at the wall to see what sticks. I managed to get a 3 node cluster working with 5 Debian/12/cloud containers for testing. The 3 host nodes are all running CachyOS (Arch derivative) with cos0 on baremetal and cos1 and cos2 on Proxmox VMs, all using ZFS storage (now that was a journey). My problem is that whatever guest is on the cos0 baremetal host will not get a IPv4 address yet an IPv6 is allocated. The two Proxmox VM host guests have no problem getting an IPV4 and if I move the guests around it’s 100% a problem with the baremetal cos0 host. Rather than dump a huge number of config files here, I thought I’d gently ask for a nudge in the right direction to work out why the guests on this one host node can’t get a v4 IP?

+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| NAME  |  STATE  |         IPV4          |                    IPV6                    |   TYPE    | SNAPSHOTS | LOCATION |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd01 | RUNNING | 192.168.1.146 (eth0) | 2403:580a:5e99:0:216:3eff:fe75:a0f8 (eth0) | CONTAINER | 0         | cos1     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd02 | RUNNING | 192.168.1.215 (eth0) | 2403:580a:5e99:0:216:3eff:fe80:c681 (eth0) | CONTAINER | 0         | cos1     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd03 | RUNNING | 192.168.1.151 (eth0) | 2403:580a:5e99:0:216:3eff:fe3a:3ed8 (eth0) | CONTAINER | 0         | cos2     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd04 | RUNNING |                       | 2403:580a:5e99:0:216:3eff:fe92:4a5b (eth0) | CONTAINER | 0         | cos0     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd05 | RUNNING |                       | 2403:580a:5e99:0:216:3eff:fef5:4c1c (eth0) | CONTAINER | 0         | cos0     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
2

Sounds like a networking issue. You created a bridge network presumably - can you show its config? What’s acting as the upstream DHCP server?

Run tcpdump on the host cos0 (listening to the bridge and/or the external interface) and inside the container ctd04/05 to look for UDP port 67/68 traffic. Are the broadcasts getting to the DHCP server? Are the responses being received by cos0, and are they being received by ctd04/05?

I’d suspect the likely problem is some unexpected traffic filtering (iptables/nftables/ebtables).

If that’s not it, then as an outside chance, you could try turning off tx checksum offloading on the virtual NIC inside ctd04/ctd05:

ethtool --offload eth0 tx off

(Many years ago I had issues with UDP checksums in virtual environments which were fixed that way, but that was when using virtual Cisco routers under dynamips emulation)

3

Hello Mark,

Could you explain a bit, how is your network configured ?

Do you use Bridge ? Macvlan ? OVN ? (to share network access on cos1 ? cos2 ? )
Could you show the result of :

incus network list
incus cluster list
incus info local: (on both cos1 and cos2… think about obfuscating the TLS Key…)

As incus uses nftables, are you adding some rules by hand, that may override what incus had done ? Could you list firewall rules on cos1 and cos2 ?

sudo nft list tables
sudo nft list chains
sudo nft list rulesets

If you’re trying to ingest NFTables rules with a file, it may override incus changes if you flush before import… :slight_smile:

Best of luck,

/joen

1 Like
4

Thanks for your response, Brian. I changed the problematic cos0 guests to static IPs and that did not make any difference, so I didn’t go down the tcpdump rabbit hole…

ctd04 ~ cat /etc/systemd/network/10-cloud-init-eth0.network
[Match]
Name=eth0

[Network]
#DHCP=ipv4
Address=192.168.1.246/24
Gateway=192.168.1.1

I have removed anything to do with firewalling from the host and all guest containers.

A good point, I tried that and on the two cos0 guests but no difference. I also vaguely remember this suggestion for the nics on this baremetal cos0 host (Minisforum MS-01), so I tried this ethtool trick there too, just in case, but still no joy.

I have manually set up a vmbr0 bridge on each host node because I want to TRY and move VM/CTs between and Incus cluster (cos0, cos2, cos3) and my Proxmox cluster with the ultimate aim of using my Proxmox Backup Servers for Incus guests too. Point being is this naive beginner just threw stuff around to get something to work, and I may not have missed some important points. I’ll post some configs next.

5

Thanks joen, I manually created vmbr0 bridges on each host node and somehow managed to get the nodes and cluster to recognise it. As explained above, I want to work with my Proxmox cluster, and it uses a default bridge of vmbr0. I have removed all firewall rules from hosts and guests. Some configs follow…

cos0 ~ incus cluster list
+------+-------------------+-----------------+--------------+----------------+-------------+--------+-------------------+
| NAME |        URL        |      ROLES      | ARCHITECTURE | FAILURE DOMAIN | DESCRIPTION | STATUS |      MESSAGE      |
+------+-------------------+-----------------+--------------+----------------+-------------+--------+-------------------+
| cos0 | https://cos0:8443 | database        | x86_64       | default        |             | ONLINE | Fully operational |
+------+-------------------+-----------------+--------------+----------------+-------------+--------+-------------------+
| cos1 | https://cos1:8443 | database-leader | x86_64       | default        |             | ONLINE | Fully operational |
|      |                   | database        |              |                |             |        |                   |
+------+-------------------+-----------------+--------------+----------------+-------------+--------+-------------------+
| cos2 | https://cos2:8443 | database        | x86_64       | default        |             | ONLINE | Fully operational |
+------+-------------------+-----------------+--------------+----------------+-------------+--------+-------------------+

cos0 ~ incus network list # baremetal Minisform MS-01
+-------------+----------+---------+------+------+-------------+---------+-------+
|    NAME     |   TYPE   | MANAGED | IPV4 | IPV6 | DESCRIPTION | USED BY | STATE |
+-------------+----------+---------+------+------+-------------+---------+-------+
| enp2s0f0np0 | physical | NO      |      |      |             | 0       |       |
+-------------+----------+---------+------+------+-------------+---------+-------+
| enp2s0f1np1 | physical | NO      |      |      |             | 0       |       |
+-------------+----------+---------+------+------+-------------+---------+-------+
| enp87s0     | physical | NO      |      |      |             | 0       |       |
+-------------+----------+---------+------+------+-------------+---------+-------+
| enp89s0     | physical | NO      |      |      |             | 0       |       |
+-------------+----------+---------+------+------+-------------+---------+-------+
| vmbr0       | bridge   | NO      |      |      |             | 6       |       |
+-------------+----------+---------+------+------+-------------+---------+-------+
| wlan0       | physical | NO      |      |      |             | 0       |       |
+-------------+----------+---------+------+------+-------------+---------+-------+

cos1 ~ incus network list # Promox VM (same for cos2)
+---------+----------+---------+------+------+-------------+---------+-------+
|  NAME   |   TYPE   | MANAGED | IPV4 | IPV6 | DESCRIPTION | USED BY | STATE |
+---------+----------+---------+------+------+-------------+---------+-------+
| enp6s18 | physical | NO      |      |      |             | 0       |       |
+---------+----------+---------+------+------+-------------+---------+-------+
| vmbr0   | bridge   | NO      |      |      |             | 6       |       |
+---------+----------+---------+------+------+-------------+---------+-------+

cos0 ~ incus info local:
config:
  cluster.https_address: cos0:8443
  core.https_address: cos0:8443
api_extensions:
- storage_zfs_remove_snapshots
- etc ...
api_status: stable
api_version: "1.0"
auth: trusted
public: false
auth_methods:
- tls
auth_user_name: markc
auth_user_method: unix
environment:
  addresses:
  - cos0:8443
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
    etc ...
    -----END CERTIFICATE-----
  certificate_fingerprint: 4fcb...
  driver: lxc | qemu
  driver_version: 6.0.0 | 9.0.0
  firewall: nftables
  kernel: Linux
  kernel_architecture: x86_64
  kernel_features:
    idmapped_mounts: "true"
    netnsid_getifaddrs: "true"
    seccomp_listener: "true"
    seccomp_listener_continue: "true"
    uevent_injection: "true"
    unpriv_binfmt: "true"
    unpriv_fscaps: "true"
  kernel_version: 6.9.0-1-cachyos
  lxc_features:
    cgroup2: "true"
    core_scheduling: "true"
    devpts_fd: "true"
    idmapped_mounts_v2: "true"
    mount_injection_file: "true"
    network_gateway_device_route: "true"
    network_ipvlan: "true"
    network_l2proxy: "true"
    network_phys_macvlan_mtu: "true"
    network_veth_router: "true"
    pidfd: "true"
    seccomp_allow_deny_syntax: "true"
    seccomp_notify: "true"
    seccomp_proxy_send_notify_fd: "true"
  os_name: CachyOS Linux
  os_version: ""
  project: default
  server: incus
  server_clustered: true
  server_event_mode: full-mesh
  server_name: cos0
  server_pid: 1496
  server_version: "6.1"
  storage: zfs
  storage_version: 2.2.3-14_g228ff3867
  storage_supported_drivers:
  - name: zfs
    version: 2.2.3-14_g228ff3867
    remote: false
  - name: btrfs
    version: 6.8.1
    remote: false
  - name: dir
    version: "1"
    remote: false
  - name: lvm
    version: 2.03.23(2) (2023-11-21) / 1.02.197 (2023-11-21) / 4.48.0
    remote: false

cos1 ~ inus info local: # same as cos2
config:
  cluster.https_address: cos1:8443
  core.https_address: cos1:8443
api_extensions:
- storage_zfs_remove_snapshots
- etc ...
api_status: stable
api_version: "1.0"
auth: trusted
public: false
auth_methods:
- tls
auth_user_name: sysadm
auth_user_method: unix
environment:
  addresses:
  - cos1:8443
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
    etc ...
    -----END CERTIFICATE-----
  certificate_fingerprint: 4fcb...
  driver: lxc | qemu
  driver_version: 6.0.0 | 9.0.0
  firewall: nftables
  kernel: Linux
  kernel_architecture: x86_64
  kernel_features:
    idmapped_mounts: "true"
    netnsid_getifaddrs: "true"
    seccomp_listener: "true"
    seccomp_listener_continue: "true"
    uevent_injection: "true"
    unpriv_binfmt: "true"
    unpriv_fscaps: "true"
  kernel_version: 6.8.9-4-cachyos
  lxc_features:
    cgroup2: "true"
    core_scheduling: "true"
    devpts_fd: "true"
    idmapped_mounts_v2: "true"
    mount_injection_file: "true"
    network_gateway_device_route: "true"
    network_ipvlan: "true"
    network_l2proxy: "true"
    network_phys_macvlan_mtu: "true"
    network_veth_router: "true"
    pidfd: "true"
    seccomp_allow_deny_syntax: "true"
    seccomp_notify: "true"
    seccomp_proxy_send_notify_fd: "true"
  os_name: CachyOS Linux
  os_version: ""
  project: default
  server: incus
  server_clustered: true
  server_event_mode: full-mesh
  server_name: cos1
  server_pid: 2864
  server_version: "6.1"
  storage: zfs
  storage_version: 2.2.3-14_g228ff3867
  storage_supported_drivers:
  - name: zfs
    version: 2.2.3-14_g228ff3867
    remote: false
  - name: btrfs
    version: 6.8.1
    remote: false
  - name: dir
    version: "1"
    remote: false
  - name: lvm
    version: 2.03.23(2) (2023-11-21) / 1.02.197 (2023-11-21) / 4.48.0
    remote: false
  - name: lvmcluster
    version: 2.03.23(2) (2023-11-21) / 1.02.197 (2023-11-21) / 4.48.0
    remote: true

cos0 ~ 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 noprefixroute 
       valid_lft forever preferred_lft forever
2: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 7a:49:c4:61:cc:60 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.234/24 brd 192.168.1.255 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 2403:580a:5e99:0:7849:c4ff:fe61:cc60/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 597sec preferred_lft 597sec
    inet6 fe80::7849:c4ff:fe61:cc60/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
3: enp87s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether 58:47:ca:77:0c:28 brd ff:ff:ff:ff:ff:ff
4: enp89s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master vmbr0 state DOWN group default qlen 1000
    link/ether 58:47:ca:77:0c:29 brd ff:ff:ff:ff:ff:ff
5: enp2s0f0np0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master vmbr0 state DOWN group default qlen 1000
    link/ether 58:47:ca:77:0c:26 brd ff:ff:ff:ff:ff:ff
6: enp2s0f1np1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master vmbr0 state DOWN group default qlen 1000
    link/ether 58:47:ca:77:0c:27 brd ff:ff:ff:ff:ff:ff
7: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 04:f4:d8:18:3c:c3 brd ff:ff:ff:ff:ff:ff
9: veth1ff771d2@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 4a:68:ef:c0:6a:c3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
11: veth0607bdbd@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 42:74:f5:5c:b8:16 brd ff:ff:ff:ff:ff:ff link-netnsid 1
cos0 ~ ip r
default via 192.168.1.1 dev vmbr0 proto static 
192.168.1.0/24 dev vmbr0 proto kernel scope link src 192.168.1.234 

cos1 ~ ip a # same/similar for cos2
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: enp6s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vmbr0 state UP group default qlen 1000
    link/ether bc:24:11:c4:66:dc brd ff:ff:ff:ff:ff:ff
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1a:63:15:80:49:6d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.208/24 brd 192.168.1.255 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 2403:580a:5e99:0:1863:15ff:fe80:496d/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 594sec preferred_lft 594sec
    inet6 fe80::1863:15ff:fe80:496d/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
7: veth04adbaa6@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 56:b1:dd:a5:62:9e brd ff:ff:ff:ff:ff:ff link-netnsid 2
9: vethc0814fda@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 56:2d:6b:cc:97:3b brd ff:ff:ff:ff:ff:ff link-netnsid 3
cos1 ~ ip r
default via 192.168.1.1 dev vmbr0 proto static 
192.168.1.0/24 dev vmbr0 proto kernel scope link src 192.168.1.208

As noted, iptables, nftables and ebtables lists are all empty.

6

Followup. I just updated all 3 host nodes and rebooted them and now…

cos0 ~ uname -a
Linux cos0 6.9.0-2-cachyos #1 SMP PREEMPT_DYNAMIC Tue, 14 May 2024 06:51:12 +0000 x86_64 GNU/Linux
cos0 ~ incus list
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+
| NAME  |  STATE  | IPV4 |                    IPV6                    |   TYPE    | SNAPSHOTS | LOCATION |
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+
| ctd01 | RUNNING |      | 2403:580a:5e99:0:216:3eff:fe75:a0f8 (eth0) | CONTAINER | 0         | cos1     |
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+
| ctd02 | RUNNING |      | 2403:580a:5e99:0:216:3eff:fe80:c681 (eth0) | CONTAINER | 0         | cos1     |
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+
| ctd03 | RUNNING |      | 2403:580a:5e99:0:216:3eff:fe3a:3ed8 (eth0) | CONTAINER | 0         | cos2     |
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+
| ctd04 | RUNNING |      | 2403:580a:5e99:0:216:3eff:fe92:4a5b (eth0) | CONTAINER | 0         | cos0     |
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+
| ctd05 | RUNNING |      | 2403:580a:5e99:0:216:3eff:fef5:4c1c (eth0) | CONTAINER | 0         | cos0     |
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+

So previously I noted that cos0 was running kernel 6.9 and cos1 and cos2 were 6.8.9 and the node with kernel 6.9 was problematic. Now they are all running kernel 6.9 and none of them are showing IPV4.

I’m inclined to think this is an Incus (and/or + kernel 6.9) bug because all the guests do actually have IPs, even via DHCP, and I can start/stop and copy/move the guests around, so the cluster seems to be fully functional. It’s just that incus list is not displaying the IPV4 column entries.

7

That’s easy enough to prove or disprove: just do

incus list ctd04
incus exec ctd04 ip addr list

and look for any IPv4 addresses in the second output.

1 Like
8

Yes, the v4 IP definitely exists in the container but doesn’t show up in the incus list output.

cos0 ~ incus list ctd04
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+
| NAME  |  STATE  | IPV4 |                    IPV6                    |   TYPE    | SNAPSHOTS | LOCATION |
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+
| ctd04 | RUNNING |      | 2403:580a:5e99:0:216:3eff:fe92:4a5b (eth0) | CONTAINER | 0         | cos0     |
+-------+---------+------+--------------------------------------------+-----------+-----------+----------+
cos0 ~ incus exec ctd04 ip addr list
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
8: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:92:4a:5b brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.246/24 brd 192.168.20.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2403:580a:5e99:0:216:3eff:fe92:4a5b/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 596sec preferred_lft 596sec
    inet6 fe80::216:3eff:fe92:4a5b/64 scope link 
       valid_lft forever preferred_lft forever
9

And presumably not in incus info ctd04 either?

That’ll be one for Stéphane then - how incus determines the container’s IPv4 address. I found this code but don’t know how it operates inside the container’s namespace.

1 Like
10

Yes, you are right, Brian. Just the IPV6 addresses as per the incus list output…

cos0 ~ incus info ctd04
Name: ctd04
Status: RUNNING
Type: container
Architecture: x86_64
Location: cos0
PID: 1676
Created: 2024/05/14 13:01 AEST
Last Used: 2024/05/15 12:00 AEST
Started: 2024/05/15 12:00 AEST

Resources:
  Processes: 9
  Disk usage:
    root: 450.10MiB
  CPU usage:
    CPU usage (in seconds): 5
  Memory usage:
    Memory (current): 92.99MiB
  Network usage:
    eth0:
      Type: broadcast
      State: UP
      Host interface: vethe1c48226
      MAC address: 00:16:3e:92:4a:5b
      MTU: 1500
      Bytes received: 7.23MB
      Bytes sent: 677.68kB
      Packets received: 64893
      Packets sent: 6654
      IP addresses:
        inet6: 2403:580a:5e99:0:216:3eff:fe92:4a5b/64 (global)
        inet6: fe80::216:3eff:fe92:4a5b/64 (link)
    lo:
      Type: loopback
      State: UP
      MTU: 65536
      Bytes received: 840B
      Bytes sent: 840B
      Packets received: 10
      Packets sent: 10
      IP addresses:
        inet:  127.0.0.1/8 (local)
        inet6: ::1/128 (local)
11

Well how about that, I restored a 4 week old Proxmox VM backup of CachyOS, added the Incus 6.1 package then added this node (cos3) to my little cluster and now the IP is showing up for the guest that I just moved from one of the host nodes running the 6.9 kernel (where the IPV4 column does not show up).

I suspect anyone using kernel 6.9 may have the same problem, and it’s just that CachyOS (Archlinux) is a rolling release, so I just happen to bump into this issue sooner than others, perhaps.

cos3 ~ uname -a
Linux cos3 6.8.6-1-cachyos #1 SMP PREEMPT_DYNAMIC Sun, 14 Apr 2024 07:23:30 +0000 x86_64 GNU/Linux
cos3 ~ incus list
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| NAME  |  STATE  |         IPV4          |                    IPV6                    |   TYPE    | SNAPSHOTS | LOCATION |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd01 | RUNNING |                       | 2403:580a:5e99:0:216:3eff:fe75:a0f8 (eth0) | CONTAINER | 0         | cos1     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd02 | RUNNING |                       | 2403:580a:5e99:0:216:3eff:fe80:c681 (eth0) | CONTAINER | 0         | cos1     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd03 | RUNNING | 192.168.1.151 (eth0)  | 2403:580a:5e99:0:216:3eff:fe3a:3ed8 (eth0) | CONTAINER | 0         | cos3     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd04 | RUNNING |                       | 2403:580a:5e99:0:216:3eff:fe92:4a5b (eth0) | CONTAINER | 0         | cos0     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd05 | RUNNING |                       | 2403:580a:5e99:0:216:3eff:fef5:4c1c (eth0) | CONTAINER | 0         | cos0     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
1 Like
12

Hello Markc, happy it all “works” even if it doesn’t looks like… i assume, it’s better that way, than the other :slight_smile:

1 Like
13

Solved the problem of the Incus API not providing the IPV4 output by downgrading all my Incus host nodes to the linux-cachyos-lts kernel. I’m not sure if it’s the latest 6.9.0 CachyOS kernel at fault or something about the generic 6.9 kernel.

cos0 ~ uname -a
Linux cos0 6.6.30-1-cachyos-lts #1 SMP PREEMPT_DYNAMIC Thu, 09 May 2024 13:58:03 +0000 x86_64 GNU/Linux
cos0 ~ il
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| NAME  |  STATE  |         IPV4          |                    IPV6                    |   TYPE    | SNAPSHOTS | LOCATION |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd01 | RUNNING | 192.168.1.146 (eth0)  | 2403:580a:5e99:0:216:3eff:fe75:a0f8 (eth0) | CONTAINER | 0         | cos0     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd02 | RUNNING | 192.168.1.215 (eth0)  | 2403:580a:5e99:0:216:3eff:fe80:c681 (eth0) | CONTAINER | 0         | cos1     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd03 | RUNNING | 192.168.1.151 (eth0)  | 2403:580a:5e99:0:216:3eff:fe3a:3ed8 (eth0) | CONTAINER | 0         | cos2     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd04 | RUNNING | 192.168.1.246 (eth0)  | 2403:580a:5e99:0:216:3eff:fe92:4a5b (eth0) | CONTAINER | 0         | cos3     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
| ctd05 | RUNNING | 192.168.1.168 (eth0)  | 2403:580a:5e99:0:216:3eff:fef5:4c1c (eth0) | CONTAINER | 0         | cos4     |
+-------+---------+-----------------------+--------------------------------------------+-----------+-----------+----------+
1 Like