Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu

[Jamie Lokier <jamie@shareable.org>]

Arnd Bergmann wrote:
> On Friday 06 November 2009, Jamie Lokier wrote:
> > 
> > Michael S. Tsirkin wrote:
> > > On Thu, Nov 05, 2009 at 04:12:36AM +0000, Jamie Lokier wrote:
> > > > I notice that if we eventually teach the kernel to have unnamed
> > > > bridges (just attach interfaces to each other), only the helper
> > > > commands will need changing to use it :-)
> > > 
> > > What do you mean by "attach interfaces to each other"?
> > > Which interfaces do you want to attach to each other?
> > 
> > For example, attaching eth0 to tap0 without having to define br0,
> > instead of the current method where you define br0 then attach eth0
> > and tap0 to it, then transfer eth0's IP configuration to br0, then
> > tell all the network management tools about it.
> 
> "Attaching" two network interfaces to each other does not work the
> way you'd like it to. The tap device is on it's own unless you use
> either a bridge or configure IP forwarding, which has another set
> of problems.

That's why I called it "unnamed bridges".  There still needs to be a
bridge doing the usual MAC learning, possibly spanning tree, etc. to
have the right behaviour.

The only trouble is having to configure the local IP settings on the
bridge itself, which entails modifying every network configuration
tool, every script and so on.

Hence the idea of allowing attached physical interfaces to have
individual local IP settings, and (perhaps) not bothering with a
separate named interface for the bridge, instead just allow brctl to
be given a physical interface and instantiate a "slave" bridge which
is always attached to that interface and referenced through it.

So instead of:

    brctl addbr br0
    brctl addif br0 eth0 # Already inherits MAC from the first attached if.
    brctl addif br0 tap0
    ifconfig br0 1.2.3.4  # Move IP configuration from eth0 to br0
    ifconfig eth0 0.0.0.0

You'd do:

    brctl addif eth0 tap0

Much simpler, and would Just Work with so many more things.  It's just
configuration sugar really.  Underneath there would still be a bridge,
using the Linux bridge code, with two interfaces attached.

> I posted an experimental 'macvtap' driver a few some time ago that
> would allow you to do something like that, i.e. add another logical
> interface to an existing eth0 device, with a separate mac address,
> and export that as a character device that is compatible with /dev/tun.

(That's not as useful as unnamed bridges because it only works with tun
devices, but that's not relevant to QEMU/KVM).

If the guest contains it's own bridges, or even it's own macvtaps, you
need bridge MAC learning (and perhaps STP to avoid cycles) to forward
packets efficiently.  Otherwise you have to either forward all packets
to the guest (won't do that obviously), or some guest configurations
just won't work as they'd expect.

Of course it's ok if "interesting" guests don't work properly.
macvtap can come with documented restrictions (they are a useful form
of security anyway), and people can use proper host bridges like they
already do for guests who need to behave like they're plugged into the
host network properly.

But imho it'd be far nicer not to have "specialness" like that unless
you want it for some positive reason like security.

> I probably need to start that one over from scratch, because I also
> want to make it work with vhost-net, and to allow the guest and
> the host to communicate with each other.
> Note that this would be transparent to qemu, we'd only need a different
> helper script to call.

Helper scripts are the new management tools I hear ;-)

-- Jamie