openvswitch agent should use veths instead of patch ports
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Won't Fix
|
Medium
|
Zang MingJie |
Bug Description
The Open vSwitch FAQ at http://
Q: What features are not available in the Open vSwitch kernel datapath
that ships as part of the upstream Linux kernel?
A: The kernel module in upstream Linux 3.3 and later does not include
the following features:
- Bridge compatibility, that is, support for the ovs-brcompatd
daemon that (if you enable it) lets "brctl" and other Linux
bridge tools transparently work with Open vSwitch instead.
We do not expect bridge compatibility to ever be available in
upstream Linux. If you need bridge compatibility, use the
kernel module from the Open vSwitch distribution instead of the
upstream Linux kernel module.
- Tunnel virtual ports, that is, interfaces with type "gre",
Linux and attach them to Open vSwitch as system devices.
However, they cannot be dynamically created through the OVSDB
protocol or set the tunnel ids as a flow action.
Work is in progress in adding these features to the upstream
Linux version of the Open vSwitch kernel module. For now, if
you need these features, use the kernel module from the Open
vSwitch distribution instead of the upstream Linux kernel
module.
- Patch virtual ports, that is, interfaces with type "patch".
You can use Linux "veth" devices as a substitute.
We don't have any plans to add patch ports upstream.
Operating systems such as Fedora that only support the "Open vSwitch kernel datapath that ships as part of the upstream Linux kernel" do not currently support GRE tunnelling with the openvswitch plugin due to the lack of both tunnel virtual ports and patch virtual ports. Since there are plans to add the former but not the latter to the upstream kernel, the openvswitch agent should be changed to use veth devices instead of patch port to link the integration bridge with the tunnel bridge. This would enable GRE networks to be supported on these systems as soon as the planned support for tunnel virtual ports is in the upstream Linux kernel.
Bob, I don't believe we're planning on doing this for Folsom. If you think it needs to be done for Folsom, let's coordinate ASAP.