I am trying to understand and get familiar with incus networking.
Fair to say that I am a bit confused. I am not sure what I should be expecting - so I am sorry if the questions seem strange:
My container has network access.
incus list shows the container IP address 192.168.43.129 (eth0)
listing instance devices returns empty incus config device list arch-container-3 - Is this normal? I thought the network device would be listed?
listing network interfaces shows a randomly generate interface name. Is this normal? incus exec arch-container-3 -- ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
12: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 10:66:6a:62:7c:9c brd ff:ff:ff:ff:ff:ff link-netnsid 0
If I try to set the ip-address on the network device incus config device set arch-container-3 eth0 ipv4.address=192.168.43.43. I get an error: Error: Device doesn't exist (maybe this doesn’t work because it is a managed network?)
incus config show arch-container-3
incus config show arch-container-3 -e
The former shows just the specific config on that container; the expanded (-e) value also shows settings inherited from the profile, and that should include your eth0.
I don’t know of an equivalent flag for incus config device list though.
If I try to set the ip-address on the network device incus config device set arch-container-3 eth0 ipv4.address=192.168.43.43. I get an error: Error: Device doesn't exist (maybe this doesn’t work because it is a managed network?)
No, it’s because you need to explicitly create a copy of the eth0 device configuration on the container, before you can change its settings (think of the eth0 inherited from the profile as being “read-only”)
But there’s a command that will do that for you in one step:
When you setup Incus, the wizard (incus admin init) will generate a managed network interface incusbr0 with private IP address 10.x.y.z. Did Incus in your case pick at random the range 192.168.x.y by itself or did you set it yourself?
Note that if you want your containers to get an IP address of your LAN, you need to use extra functionality (macvlan, or make a bridge br0 for the host network then attach on there the containers, routed, ipvlan, etc).
In here, the first occurrence of incusbr0, is the name of the interface that will appear in the container. Here, you typically set it to eth0 which is as much of a default name you can choose. You can obviously set it to anything else, however it may confuse rather than help.
The network: incusbr0 refers to some network interface on the host and if you keep the default naming, it’s the network interface name of the networking that is managed by Incus for you.
I do not understand how you manage to override the IP address of the interface in the container to be part of 192.168.x.y. It should not have allowed you to do so.
Perhaps you want to show the output of incus network list.
Simos, yesterday I really struggled to understand what was going on with my networking set up. I followed your guide to change the bridge IP address to 198.168.43.0/8 (I am planning a very small set of containers)
Then my instances started getting the IP addresses (as expected in the range of the bridge IP address)
My problem began, when I tried to follow another guide to override the interface IP address to be static…
As you pointed out, I don’t know why my default (out of the box) profile had network interface incusbr0 (it should be eth0) - not sure what I did during initializtion of incus to produce this default profile…it really confused me when I tried to follow guides, etc.
I think I know what’s going on now, and I will change my default profile accordingly.
Here is the output you requested
❯ incus network list 05:39:06
+----------+----------+---------+-----------------+--------------------------+-------------+---------+---------+
| NAME | TYPE | MANAGED | IPV4 | IPV6 | DESCRIPTION | USED BY | STATE |
+----------+----------+---------+-----------------+--------------------------+-------------+---------+---------+
| enp7s0 | physical | NO | | | | 0 | |
+----------+----------+---------+-----------------+--------------------------+-------------+---------+---------+
| incusbr0 | bridge | YES | 192.168.43.1/24 | fd42:a6c:1df8:480f::1/64 | | 7 | CREATED |
+----------+----------+---------+-----------------+--------------------------+-------------+---------+---------+
| lo | loopback | NO | | | | 0 | |
+----------+----------+---------+-----------------+--------------------------+-------------+---------+---------+
Your containers either get their network configuration from a managed network (by Incus), or they get it from an unmanaged network (you would need to configure that router), or get a guerilla/unannounced static IP without informing their managed/unmanaged networks.
If you want to get a proper static IP (remains the same), you can configure Incus to give the same IP address from the managed network. You do that with ipv4.address=1.2.3.4 for the container.
Having said that, I am mystified as to why incusbr0 has a 192.168. IP address. Most likely some guide had instructions on setting the IP address in that range. And if your host is on the same range, then networking is likely not to work.
To figure out what’s going on, you can create a new managed network and see what IP address it will take. In the following please verify that incusbr5 gets an address in the 10..... range.
$ incus network create incusbr5
Network incusbr5 created
$ incus network list
...
If so, then you can edit incusbr0 to get the 10.10.10.1/24 address which is nice and pleasant to look at. See my post about that. (Hint: incus network edit incusbr0). Also, use eth0 for the name of the interface in the container instead of incusbr0.
Now, your container will get a static/same IP address. Here is an example.
If, instead, you want your container to get an IP address from the host’s network (otherwise called, from the LAN), then you would do something else that does not involve the incusbr0 managed(by Incus) network interface.