I agree that this is a useful behavior, often we will use a bridge in the same scenario (multiple virtio tap adapters belonging to VM's) another scenario is when creating a bridge for chaining multiple VPN's together. -Joel On 14 March 2013 06:04, Vlad Yasevich <vyasevic@xxxxxxxxxx> wrote: > On 03/13/2013 12:09 PM, Stephen Hemminger wrote: >> >> On Wed, 13 Mar 2013 11:45:40 -0400 >> Vlad Yasevich <vyasevic@xxxxxxxxxx> wrote: >> >>> On 03/13/2013 11:39 AM, Stephen Hemminger wrote: >>>> >>>> On Wed, 13 Mar 2013 08:12:29 -0400 >>>> Vlad Yasevich <vyasevic@xxxxxxxxxx> wrote: >>>> >>>>> On 03/13/2013 02:22 AM, "Oleg A. Arkhangelsky" wrote: >>>>>> >>>>>> >>>>>> >>>>>> 13.03.2013, 05:45, "Vlad Yasevich" <vyasevic@xxxxxxxxxx>: >>>>>> >>>>>>> The series adds an ability for the bridge to function in >>>>>>> non-promiscuous mode. >>>>>> >>>>>> >>>>>> What is the practical applications for such setup? In other words, >>>>>> in which cases I would want to put bridge into non-promiscuous >>>>>> mode and specify some uplink ports? >>>>>> >>>>> >>>>> On of the applications would be when bridge is an edge device servicing >>>>> a VM deployment. Each of the VMs knows the mac address that the guest >>>>> has and may program that mac onto the uplinks. >>>> >>>> >>>> Why wouldn't that environment just use macvlan? >>>> Is it because changing libvirt is harder than changing the kernel? >>>> >>> >>> No, because macvlan has a drawback that it doesn't easily let guests >>> talk to the host. Bridge is still most commonly used for just that >>> reason. >>> >>> -vlad >> >> >> Maybe fixing that with a flag to macvlan would be easier? >> > > Not really. macvlan to physical device could be made simple enough. > However, physical to macvlan is non-trivial at all. > > We get around this right now by crating a macvlan on the host and > have macvlan to macvlan communication essentially turning it into > bridge. But that doesn't work in all scenarios either. > > -vlad
