I’m continue experimenting with incus and microovn integration. I created managed bridge with the bridge.driver=openvswitch and found warnings like below in the logs afterwhile:
2025-06-13T21:47:36.504962-07:00 picl-06 ovs-vswitchd: ovs|00142|bridge|WARN|could not open network device veth078cf688 (No such device)
2025-06-13T21:47:36.552032-07:00 picl-06 ovs-vswitchd: ovs|00143|bridge|WARN|could not open network device veth2b6337a4 (No such device)
2025-06-13T21:47:36.562613-07:00 picl-06 ovs-vswitchd: ovs|00144|bridge|WARN|could not open network device veth2ddff16b (No such device)
After the investigation I found that these warning are related to leftover ports connected to the containers’ network interfaces were running on this incus cluster node before it was rebooted.
I suspect that the incus daemon does not remove ports attached to the container interfaces when incus cluster node shutdowns or restarts.
The Incus host shutdown logic matches the logic used in a regular incus stop, so if incus stop works correctly but the host shutdown doesn’t, then it may be interesting to know if Incus was correctly able to shut down the instances or if the timeout was hit and systemd just went on to kill everything off (which would then definitely result in such leftovers).
I do not see such warnings on restarting incusd with systemctl incus stop incus incus.socket && systemctl incus start incus incus.socket or systemctl incus restart incus incud. What I see - incusd does not stop running containers when it shutdowns or restart from systemd. So, it does not update the bridge in this case. In case of reboot, the ovs keeps links to ports needs to be attached to the bridge and reports this warning on start.
One more interesting observation is the log message in the incusd start: 2025-06-14T12:29:40.307375-07:00 picl-07 incusd[71012]: time="2025-06-14T12:29:40-07:00" level=error msg="Failed initializing network" err="Failed starting: External interface \"brTest\" already in use" network=brTest project=default
I to not have any instances in the project default and only a few instances attached to the brTest network in a single project.
The incus.service unit doesn’t cause instances to stop or start, otherwise every update of Incus would lead to every instance restarting.
Instead that’s the job of the incus-startup job which starts on system boot and causes the instances to start up and which on system shutdown triggers the clean shutdown of all instances.
incus-startup stop (or incusd shutdown) removes the ovs bridge(s) at the node (brTest in my case). No warning in the log after incusd is started.
However, if I disable the incus start on boot via systemctl disable incus incus.socket and reboot the node the ovs bridge brTest and previously attached ports are still exists in the system: >ovs-vsctl list-ports brTest
You should be able to use systemctl edit to put some overrides in place.
Either editing the OVN services to use an Before=incus.service incus-startup.service so they start before and therefore get stopped after the Incus ones.
Or the other way around, adding an override to the Incus units to start after the OVN ones and therefore stop before them.
Yeah, A saw that already and updated systemd’s incus.service files at my test cluster nodes. I would suggest to add support for the microovn (and microceph as well).
I think appending After=' clause in the incus.service with snap.microovn.switch.service snap.microceph.osd.service is safe even microovn and microceph snaps are not installed.
Do you think I can create the Feature request issue?
