On Fri, Apr 12, 2024 at 05:44:36PM -0500, Ian Pilcher wrote:
On 4/12/24 16:46, Adam Williamson wrote:
> it seems since I last looked at this, NM has grown some level of
> openvswitch support, but it seems to be limited, and I don't know off-
> hand if it's sufficient for what openQA needs. I will need to look into
> that.
>
https://github.com/NetworkManager/NetworkManager/blob/main/man/nm-openvsw...
I've attempted to use it on a couple occasions, and I've never been
able to get it to work. It requires creating 3 different objects,
Right, that's because the OVS support in NM is modeled after the ovsdb
schema, with separate entities for bridges, ports and interfaces. When
you create a bridge with 'ovs-vsctl add-br br1', that actually
generates 3 objects:
# ovs-vsctl show
Bridge br1
Port br1
Interface br1
type: internal
If there was only a single NM connection profile for the whole bridge,
it wouldn't be possible e.g. to attach another interface to port
"br1", or to describe more complex setups in a declarative way.
in the correct order, with exactly the right settings.
The order shouldn't matter; if it does, that seems a bug.
If it helps, "man nm-openvswitch" provides an overview of OVS support
in NM.
And AFAIK, it still doesn't support setting the internal port to
the
same name as the bridge itself, which is the default behavior of
ovs-vsctl and the network scripts, so it's a disruptive change to the
network configuration even if it can be made to work.
This configuration is certainly supported. If you found any problems,
please report a bug.
Beniamino