Code change:
When using incus with openvswitch, incus needs to have openvswitch in its path for features involving openvswitch to work. As a result, when attaching an openvswitch as a bridged interface in incus, we encounter issues such as veth interface remaining active when it should be cleaned up, not being able to use openvswitch to make bridges, etc. It is not so urgent because it's easy enough to add it to the path, but it caused me some trouble until I figured out the cause. Enable openvswitch, enable incus, run "incus network create BRIDGENAME —type bridge " and notice that incus does not detect openvswitch. If openvswitch is enabled, openvswitch will be to incus's path, and the above command will not fail. Can be resolved by adding = [ pkgs.openvswitch ]; Maybe just need to check if openvswitch enabled, and if so, add it to the path by default? <!-- --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Do you have a vswitch configuration you're able to share?
Yes, but if I configure it using nixos, I get other problems (incus is deleting the whole bridge whenever I shut down a container and I don’t know what part of nixos is responsible for it), so I have switched to configuring it with networkmanager, where it all works well, as long as I add openvswitch to path. But here is a very simple example with a nixos configuration: = true; networking.vswitches = { br0 = { interfaces = { eth0 = { }; }; }; }; networking.interfaces.vmbr0.useDHCP = true; Just adjust eth0 to whatever device you want to add to the bridge. Then in incus, we can add a profile. Easy way to do this is set up the default profile. Then we copy it to a new one: incus copy profile default ovstest and edit it incus profile edit ovstest Then replace the networking eth0 part with the below: devices: eth0: name: eth0 nictype: bridged parent: br0 type: nic Then make a container on the profile: incus launch images:debian/bookworm mycontainer —profile ovstest It should work fine, but (this is a bug I think I haven’t reported because it could be my own stupidity) when you stop the container incus stop mycontainer All of your configured bridges will be missing, completely. So the way I do it now is enabling network manager. We can add eth0 to a network manager-defined ovs bridge this way: Setting it up like this, and adding the line below, everything is working as expected. (If I don’t add the path = line, the virtual ethernet devices don’t get cleaned up when incus shuts down a container, which is why I filed the bug report to try to have it included default) = { path = [ pkgs.openvswitch ]; Hopefully this answers what you are looking for.
Thanks! Sounds like you have a workaround until this can get fixed in the module. I'm not quite sure why your bridge is being removed when the container is stopped. You could try creating a bridge instead, but then it looks like you should be setting I tried to test this, but creating an ovs bridge yields:
I think it is because that ovs bridge doesn't exist yet. If you just attach a pre-existing ovs bridge to the container, it will work. Regular linux bridges defined with the nixos configuration also have the same disappearing problem, but with networkmanager work fine.
Actually the error I encountered is a bug.
I'm not able to reproduce your issue where the stopping of the container removes a bridge from the host. Are you on 23.11 or unstable?
This is on 23.11.
If you are able, can you try and reproduce the bridge removal using nixos unstable?
Sure, I will give it a go.
So, yes, I can reproduce it on unstable. Both with linux switches and with openvswitch switches. Here is all of the configuration related to networking. You can see the commented lines would be how I set up the linux bridges when testing them. = true; virtualisation.vswitch.resetOnStart = true; networking.useDHCP = false; networking.hostName = "boss"; = true; = "eth0"; networking.interfaces.vmbr0.ipv4.addresses = [{ address = "192.168.0.2"; prefixLength = 24; }]; = [{ address = "0.0.0.0"; prefixLength = 0; via = "192.168.0.1"; options = { metric = "100"; }; }]; = "eth1"; networking.interfaces.vmbr1.ipv4.addresses = [{ address = "192.168.1.2"; prefixLength = 24; }]; = [{ address = "0.0.0.0"; prefixLength = 0; via = "192.168.1.1"; options = { metric = "101"; }; }]; "" = true; = false; networking.nameservers = ["1.1.1.1" "8.8.8.8”];
I have created a pull request to resolve the path issues.

Related discussion:
text: boot.initrd.systemd.enable = true; }; }; lxd-to-incus = import ./lxd-to-incus.nix { inherit system pkgs; }; <ins> openvswitch = import ./openvswitch.nix { inherit system pkgs; }; </ins> preseed = import ./preseed.nix { inherit system pkgs; }; socket-activated = import ./socket-activated.nix { inherit system pkgs; }; ui = import ./ui.nix {inherit system pkgs;};