2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-31 06:15:47 +00:00

FAQ: Add an entry about reconfiguration

It seems that the behaviour is not so intuitive.
cf. https://bugs.launchpad.net/neutron/+bug/1346861

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Acked-by: Ben Pfaff <blp@nicira.com>
This commit is contained in:
YAMAMOTO Takashi
2014-09-18 13:44:52 +09:00
parent 2654cc338b
commit dd63a57e55

26
FAQ
View File

@@ -731,6 +731,32 @@ A: It depends on mechanisms and configurations you want to use.
you want to use ebtables rules.) On NetBSD, you might want to
consider using the bridge(4) with BRIDGE_IPF option.
Q: It seems that Open vSwitch does nothing when I removed a port and
then immediately put it back. For example, consider that p1 is
a port of type=internal:
ovs-vsctl del-port br0 p1 -- \
add-port br0 p1 -- \
set interface p1 type=internal
A: It's an expected behaviour.
If del-port and add-port happen in a single OVSDB transaction as your example, Open vSwitch always "skips" the intermediate steps.
Even if they are done in multiple transactions, it's still allowed
for Open vSwitch to skip the intermediate steps and just implement
the overall effect. In both cases, your example would be turned
into a no-op.
If you want to make Open vSwitch actually destroy and then re-create
the port for some side effects like resetting kernel setting for the
corresponding interface, you need to separate operations into multiple
OVSDB transactions and ensure that at least the first one does not have
--no-wait. In the following example, the first ovs-vsctl will block
until Open vSwitch reloads the new configuration and removes the port:
ovs-vsctl del-port br0 p1
ovs-vsctl add-port br0 p1 -- \
set interface p1 type=internal
Quality of Service (QoS)
------------------------