Static ip mapping on managaged network interface

What is the best way to make static reservations for the dhcp (dnsmasq) running for a managed network interface?

I tried to add via a mapping the dnsmasq way setting an ip from the range like

incus network edit incusbr0
  raw.dnsmasq: |-
    dhcp-host=00:14:3e:c6:40:a9,10.168.1.227
    host-record=db.my.org,10.168.1.227,86400
    addn-hosts=/etc/hosts

but this seems to not have any effect.
Just for testing I also removed the entry from `/var/lib/incus/networks/incusbr0/dnsmasq.leases or modified an entry and then restarted incus.service without any change.

On the network (incus network edit foo) you should be be able to set ipv4.dhcp.ranges to a value which excludes the address(es) that you want to reserve, e.g.

ipv4.dhcp.ranges: 192.168.1.2-192.168.1.20,192.168.1.22-192.168.1.254

Reference

1 Like

ok sure - I can reduce the dynamic range and set up the ip/network in the container itself without dhcp.

What I’m more after is how could I make a specific lease (with a specifi ip from the pool) to stay forever similar to the configuration above. That way you could just copy a container, move it to another cluster and you don’t have to worry about the container’s internal network

You simply apply the address you want to the container config:

devices:
  eth0:
    ipv4.address: 192.0.2.9
    ipv6.address: fdfd::9     # this requires ipv6.dhcp.stateful on the network
    name: eth0
    network: bridge0
    type: nic

I suggest you choose an address which is within the managed network subnet, but outside the dynamic DHCP pool. (I am guessing incus is clever enough to exclude all container assignments from pool allocations; but if you move it to another cluster and want to keep the same IP, obviously you don’t want another container in the target cluster to have picked up that address dynamically already)

1 Like

Hi @candlerb,
thanks for your feedback.

incus config device override <instance_name> eth0 ipv4.address=<addr> 

is what I currently do for that instance but what I had in mind is to have dhcp address mapping on a single incus host like we usually do in a incus unmanaged bridged network in other networks: we set the “static ip” on the dhcp server. This allows us to move a container between networks and to be sure the container will allways get the same network specific address which fits to that subnet - even months later.
Since incus uses dnsmasq on it’s managed networks I thought it should be possible to do the mac/ip config the dnmasq way (dhcp-host=<mac>,<ip>)

That is what incus does in the background. But the way you configure it is to apply the mapping to each container’s NIC.

You’ll find the mappings incus creates in separate files like

/var/lib/incus/networks/<bridge>/dnsmasq.hosts/<project>_<container>.eth0

Then dnsmasq runs with --dhcp-hostsfile=/var/lib/incus/networks/<bridge>/dnsmasq.hosts to pick up all the files in that directory.

2 Likes

Hello,

In Incus Version 6.8, the container dnsmasq host file has the configured ipv4.address in the container config but removing dnsmasq.leases, reloading the container and restarting incus does not seem to work. The container still has its original DHCP address.

config:
  ipv4.address: 172.16.12.1/24
  ipv6.address: fd42:8947:f637:1cf2::1/64
  ipv6.nat: "true"
  raw.dnsmasq: |
    listen-address=172.16.12.1
    dhcp-host=00:16:3e:70:79:0c,172.16.12.16
    dhcp-host=00:16:3e:a2:26:91,172.16.12.15
    dhcp-host=00:16:3e:6c:cc:53,172.16.12.14
    dhcp-host=00:16:3e:a4:90:ed,172.16.12.13
    dhcp-host=00:16:3e:ed:6e:98,172.16.12.12
    dhcp-host=00:16:3e:b3:e8:f2,172.16.12.11
    dhcp-host=00:16:3e:ae:9a:5d,172.16.12.10
    address=/svc.ocp.jkary.net/172.16.12.10
    address=/bootstrap/172.16.12.10
    address=/ocp-cp-1.ocp.jkary.net/172.16.12.11
    address=/ocp-cp-2.ocp.jkary.net/172.16.12.12
    address=/ocp-cp-3.ocp.jkary.net/172.16.12.13
    address=/ocp-w-1.ocp.jkary.net/172.16.12.14
    address=/ocp-w-2.ocp.jkary.net/172.16.12.15
    address=/ocp-w-3.ocp.jkary.net/172.16.12.16
    ptr-record=10.12.16.172.in-addr.arpa,bootstrap.ocp.jkary.net
    ptr-record=11.12.16.172.in-addr.arpa,ocp-cp-1.ocp.jkary.net
    ptr-record=12.12.16.172.in-addr.arpa,ocp-cp-2.ocp.jkary.net
    ptr-record=13.12.16.172.in-addr.arpa,ocp-cp-3.ocp.jkary.net
    ptr-record=14.12.16.172.in-addr.arpa,ocp-w-1.ocp.jkary.net
    ptr-record=15.12.16.172.in-addr.arpa,ocp-w-2.ocp.jkary.net
    ptr-record=16.12.16.172.in-addr.arpa,ocp-w-3.ocp.jkary.net
    srv-host=_etcd-server-ssl._tcp,etcd-0.ocp.jkary.net,0,10,2380
    srv-host=_etcd-server-ssl._tcp,etcd-1.ocp.jkary.net,0,10,2380
    srv-host=_etcd-server-ssl._tcp,etcd-2.ocp.jkary.net,0,10,2380
    cname=api,api-int,*.apps,bootstrap.ocp.jkary.net
description: ""
name: lab03
type: bridge
used_by:
- /1.0/instances/bootstrap
- /1.0/instances/ocp-cp-1
- /1.0/instances/ocp-cp-2
- /1.0/instances/ocp-cp-3
- /1.0/instances/ocp-w-1
- /1.0/instances/ocp-w-2
- /1.0/instances/ocp-w-3
- /1.0/profiles/openshift
managed: true
status: Created
locations:
- none
project: default

Is this a bug?