I have helped 5 people to let their instances get ip from lan. And there are more posts in this forum asking about it. And there are even more posts about it if you use search engines.
And I know How to add a routed NIC device to a virtual machine exits. But I think it should be in network session instead of instances.
And incus document does tell how user can do it in Use an existing network interface by adding it as a network device to your instance.
So why so many people still asking about it. No offence, because people really will not read document throughly, they just skim, and they may not see it.
So, here I suggest give unmanaged networks a very big header like managed networks.
There are many ways that an instance can get a public IP. I think there should be a general page that lists all the methods (bridged br0, routed, macvlan, etc), then individual pages for each.
I think is “Configure routes”.
If it’s call “Configure static routes”, readers will be confused. Because normally when you config static route in router, it let 2 network communicate to each other, like 192.168.1.0/24 with 192.168.2.0/24.
If it’s call “Configure routes”, readers will know it’s going to assign ip subnets. But it is confuse too, because it doesn’t assign ip subnets, it’s a bridge just act as a switch, actually a router connect to it is the one assigns ip subnets. But if it’s call “Configure switchs”, will confuse more, readers will assume they are going to config L2 or L3 switchs. Nor can it be “Configure bridges”, because it’s a part of bridge configuration.
Or we call it “network passthrough”. I don’t know what the english words VMware use in vm network config, but it means passthrough. But VMware doesn’t passthrough nic to VMs, host can still use the physic port. I don’t know how they did, but it works.
Add physic nic to instances should be puted in passthrough.
And I think “How to configure network forwards” also need to be puted in External networks, and change name to “port forwarding”.
@stgraber Here are 2 methods for instances connect to unmanaged networks. It’s not a lot, doesn’t need a lot of time to edited. Can you recommend my suggestion to whoever manage incus document?
Physic port
Physic port can be real physic port or virtual physic port.
incus config device add instance eth0 nic name=physicalport nictype=physical parent=physicalport
When adding a physic port to an instance, if the name is eth0, it will not show if use ip a, I don’t why, just give it same name in host.
ip a
it will show nic name which in this case is physicalport as we declared above.
Because incus only will auto connect eth0 to network. So we need to config the new nic to connect to network. Edit /etc/systemd/network/eth0.network if using Systemd-networkd.
Then restart Systemd-networkd: systemctl restart systemd-networkd
I find after adding a virtual physic port(physicalport in this case) to instance, the port disappeared in host and a new port was created. I think it may pollute bridge.
bridged bridge
incus config device add instance eth0 nic name=eth0 nictype=bridged parent=br0
Restart Systemd-networkd: systemctl restart systemd-networkd, that’s all it need.
There is a veth created after adding an instance to br0. I’m using ovs bridge, and I find a lot of deprecate veths still exist after corresponding instances deleted.
But I still recommend use this way for instances connect to unmanaged networks.
Incus is using the Diataxis/Divio approach for technical documentation.
This means that there are four types of documents,
tutorials
how-tos
reference
explanation
It’s fine to make changes and edits to the documentation. Just like with the code, you can use github to make a change/edit to the documentation (same repository as the code of Incus).
Indeed, the placement of routed under Instances looks to be out of place.
In External networks, there’s a description of what goes in. If routed matches the description, then you can straight away file an issue on Github to move the howto document on routed under the Enternal networks. This would be an easy change.