I often use Incus to prototype functionality before implementing it on physical systems. It works wonderfully for this purpose. However, sometimes I need to try different things in order to decide which approach to take. I am trying to use projects to keep the different approaches distinct but have run into a problem that using the same IPv4 address range for the same conceptual network in different projects results in an error message.
A highly simplified example shows the problem. First create the try1 project:
$ incus project create try1
$ incus project switch try1
$ incus network create int-try1 ipv4.address=192.168.0.124 ipv4.nat=false
Then create the try2 project:
$ incus project create try2
$ incus project switch try2
$ incus network create int-try2 ipv4.address=192.168.0.1/24 ipv4.nat=false
Error: The DNS and DHCP service exited prematurely: exit status 2 ("dnsmasq: failed to create listening socket for 192.168.0.254: Address already in use")
From this I infer that networks are an Incus-level concept and not a project-level concept. (But it seems like they could be project-level through the use of network namespaces.)
Is this a current limitation or a fundamental one? Or more likely, am I unaware of some setting that will make this work as expected?
Note: the obvious work-around is to use different IP ranges for the different projects, which isn’t too inconvenient for my current prototype. But it seems like it would be a problem for multi-tenancy as each tenant could choose the same address range and cause the collision. Hence why I suspect I am missing something.
BTW, the reason I’d rather not use different IP address ranges is because I want the exact same configurations as will be deployed on the physical systems. That way the prototype becomes a digital twin with all the benefits that provides.