Re: [Qemu-devel] Guest bridge setup variations

[Arnd Bergmann]

On Friday 11 December 2009, Anthony Liguori wrote:
> Arnd Bergmann wrote:
> >> 3) given an fd, treat a vhost-style interface
> >
> > This could mean two things, not sure which one you mean. Either the
> > file descriptor could be the vhost file descriptor, or the socket or tap 
> > file
> > descriptor from above, with qemu operating on the vhost interface itself.
> >
> > Either option has its advantages, but I guess we should only implement
> > one of the two to keep it simple.
> >   
> 
> I was thinking the socket/tap descriptor.

ok.

> > Right. I wonder if this helper should integrate with netcf as an 
> > abstraction,
> > or if we should rather do something generic. It may also be a good idea
> > to let the helper decide which of the three options you listed to use
> > and pass that back to qemu unless the user overrides it. The decision
> > probably needs to be host specific, depending e.g. on the availability
> > and version of tools (brctl, iproute, maybe tunctl, ...), the respective
> > kernel modules (vhost, macvlan, bridge, tun, ...) and policy (VEPA, vlan,
> > ebtables). Ideally the approach should be generic enough to work on
> > other platforms (BSD, Solaris, Windows, ...).
> 
> For helpers, I think I'd like to stick with what we currently support, 
> and then allow for a robust way for there to be independent projects 
> that implement their own helpers.   For instance, I would love it if 
> netcf had a qemu network "plugin" helper.

Moving netcf specific qemu helpers into the netcf project sounds good.
I'm not sure what you mean with 'stick to what we currently support',
do you mean with helpers that ship with qemu itself? That sounds
reasonable, though I'd obviously like to make sure they also work
with macvtap, which is currently not supported unless you pass an
open file descriptor into -net tap,fd.

> There's just too much in the networking space all wrapped up in layers 
> of policy decisions.  I think it's time to move it out of qemu.

Yes.

        Arnd