Bug 1285005 - [RFE] Allow more then one ovsdb-server, ovs-vswitchd pair on a single machine [NEEDINFO]
[RFE] Allow more then one ovsdb-server, ovs-vswitchd pair on a single machine
Product: Red Hat OpenStack
Classification: Red Hat
Component: openvswitch (Show other bugs)
9.0 (Mitaka)
Unspecified Unspecified
medium Severity medium
: ---
: 8.0 (Liberty)
Assigned To: Open vSwitch development team
Ofer Blaut
: FutureFeature, ZStream
Depends On:
  Show dependency treegraph
Reported: 2015-11-24 11:18 EST by John Schwarz
Modified: 2017-05-03 13:10 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-05-03 13:10:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
fleitner: needinfo? (jschwarz)

Attachments (Terms of Use)

  None (edit)
Description John Schwarz 2015-11-24 11:18:31 EST
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:

Therefore, this RFE is about allowing more than one OVS at the same time.

How reproducible:

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:
Comment 1 Thadeu Lima de Souza Cascardo 2015-11-24 11:21:28 EST
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?

Comment 3 Flavio Leitner 2017-01-12 13:45:51 EST
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?
Comment 4 Assaf Muller 2017-01-12 14:57:37 EST
We'd like to simulate multi-node on a single host for OpenStack Neutron inter-process testing:

Here's a PoC patch John and I worked on a while ago, that we had to abandon due to this bug:
Comment 5 Aaron Conole 2017-01-13 14:56:00 EST
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).
Comment 6 Flavio Leitner 2017-03-22 01:14:25 EDT

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?
Comment 7 Flavio Leitner 2017-05-03 13:10:32 EDT
I am closing this due to the lack of replies.
Feel free to re-open if you have additional information to provide.

Note You need to log in before you can comment on or make changes to this bug.