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. > 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
