Description of problem: Currently OVS does not allow more than a single OVS pair to run concurrently on a single machine. Creating 2 pairs, each with a different db.conf and other filesystem environments, results in each pair deleting each other's bridge interface. An example codepath that deletes the other's bridge can be found here: https://github.com/openvswitch/ovs/blob/eaa923e383ed21022be408c0f83a8b89668c137c/ofproto/ofproto-dpif.c#L966 Therefore, this RFE is about allowing more than one OVS at the same time. How reproducible: 100% Steps to Reproduce: 1. Create 2 pairs of (ovsdb-server, ovs-vswitchd), each with his own db.conf and other filesystem environments 2. 'ovs-vsctl add-br test1' 3. 'ip a' shows that 'test1' exists. 4. 'ovs-vsctl add-br test2' Actual results: 'ip a' shows that test1 has been removed and test2 doesn't exist, even though 'ovs-vsctl show' will still show those bridges. Expected results: No interface should be deleted. Additional info:
This happens because OVS assumes it owns the datapath for itself, and does not allow other programs to use the datapath, even itself. Thing is, the OVS module allows multiple datapaths. But OVS only uses ovs-system. This would require that every vswitchd or netlink dpif uses a different datapath, maybe ovs-system-uuid? Cascardo.
I understand the issue but not the use-case. Why would you need to run multiple OVS in the same host? So, what's the use-case?
We'd like to simulate multi-node on a single host for OpenStack Neutron inter-process testing: http://docs.openstack.org/developer/neutron/devref/development.environment.html#fullstack-tests Here's a PoC patch John and I worked on a while ago, that we had to abandon due to this bug: https://review.openstack.org/#/c/234941/
There are other issues with this than just the database. IIRC, there can only be one upcall endpoint - that means forwarding will behave strangely, and it might really mess up all of your inter-connectivity. Additionally, the netlink monitors might collide mid-air and introduce LOTS of additional bugs. There's a lot of work for this, and possibly a redesign of the upcall interface (I haven't looked at that code in a while, so I could remember it incorrectly).
Hi, As Aaron said, OVS daemons own the datapath, so it's not possible to run another instance of the daemons. However, the OVS module and the sockets are namespace aware, so it should be possible to run multiple instances of OVS daemons in different namespaces. Does that work for you?
I am closing this due to the lack of replies. Feel free to re-open if you have additional information to provide.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days