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.
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)
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>)
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.
Is there maybe a less hacky way to configure IPs? And is it safe to use a non-reserved network for incus? Because I have a bridge already where I have traffic to some networks, and I would like my incus containers or VMs to use the same network, shared with other systems which are not managed by incus.
It’s not hacky at all (“hacky” is only if you try to configure the internal dnsmasq in incus).
Just define a bridge on your incus host (not in incus) and the bridge will be visable in incus as managed=no. You then can set the container/vm network adapter to be attached to this bridge. The easiest way is to define a profile (e.g. “bridged”) and add this to the instance (in this example the OS bridge is called br2):
If the network of br2 does not have a running dhcp you will need to configure your network in the instance using netplan.
Be careful when running incus in a (VMWare) VM because bridging is not possible by default since VMWare’s vSwitch is filters incoming network packages on the MAC assigned to the VM network adapter(s). The vSwitch has no MAC learning capabilities like a real switch. As a work around you may define your separate port group for incus allowing promiscuous mode and mac address changes.