On 07/13/2012 01:56 AM, Jesse Gross wrote:
On Jul 12, 2012, at 6:05 AM, Konstantin Khorenko<[email protected]> wrote:
Hi Jesse,
thank you very much for your reply, please see inline.
On 07/06/2012 06:11 AM, Jesse Gross wrote:
On Wed, Jul 4, 2012 at 9:27 AM, Konstantin Khorenko<[email protected]>
wrote:
So can you please clarify:
* is that info in FAQ still valid and the work for "patch" inclusion in
mainstream is in progress?
* i failed to find any preliminary patches in the web, but if you have any -
can you please share it or just tell me where should i look for it?
There's no work in progress or planned to add patch ports upstream.
I'm not enthusiastic about doing it either as I would like to remove
uses of it rather than add more.
What is your use case?
So, our case is the following:
let's assume we have a Node with physical interfaces ethX and a set of
Containers (CTs)/Virtual Machines (VMs) with virtual interfaces which are
visible on the Node as vethY.
We plan to implement the following scheme:
---[br0 (eth0)]---
---[br1 (eth1)]---
---[brX (ethX)]------[vbrX (vethA, vethB, ...)]
---[vbrZ (vethM, vethN, ...)]
So we want to create a number of bridges - one per physical interface on the
Node,
each bridge contains the corresponding physical interface.
Node administrator might want group CTs/VMs:
a) CTs/VMs with interfaces bridged with a particular physical interface on the
node (there can
be several such groups surely)
b) CTs/VMs with the "host only" access
So we'd like to create separate bridges for all groups from a), as well as for
groups b) and c).
If the administrator decides that CTs/VMs from group G should work in the
bridged mode via
physical interface P, we simply connect brP and vbrG with help of "patch"
functionality.
There are several advantages of this scheme:
1) if the administrator needs to reconfigure CTs/VMs group G to work via
physical
interface P1, all we need is to destroy the original "patch" connection
with brP and create
another one with brP1.
You should be able to group ports in a manner similar to different bridges
using flows. This is going to be much more efficient.
If you really want to do it with multiple bridges you could use veths but
you'll have to configure them through some other mechanism.
Yes, veths is the exact way we were thinking about as an alternative,
and thank you for the interesting idea about using flows - we definitely need
to take it into the consideration.
2) adding a new CT/VM to any group (or even stopping/starting an old one) does
not lead to brX
bridges MAC address changes, consequently network connections to any CT/VM
in the group will
not be affected (this problem arises if we use a single bridge for both
physical interface
and virtual ones).
You can always manually set the bridge's MAC addresses.
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
