Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QDES)

[Mike Lovell <mike@dev-zero.net>]

On 11/27/2012 07:24 AM, Anthony Liguori wrote:
> Stefan Hajnoczi <stefanha@gmail.com> writes:
>
>> The part I'm wondering about with VXLAN multicast is whether all QEMU
>> processes on the host need to receive on the same well-known UDP port.
>>   Not sure if that's possible with the sockets API.
> Perhaps this is a dumb question, but wouldn't it be trivial to write a
> VXLAN proxy that added a VXLAN tag to ethernet frames from -net socket?

this is definitely possible. when i was doing my initial prototyping to 
see if this would be possible, i used the socket network backend to 
connect to a python program doing the VXLAN-like processing. really ugly 
code that isn't worth reviving.

i liked the idea of having this in qemu since it would simplify 
configuration and wouldn't require starting two processes and wiring 
them together. some will probably call this crazy but i still end up 
using the cli a lot and i wanted to make that simpler. this just 
requires specifying the multicast address and the network id to qemu.

maybe there is a compromise between using the sockets api and cli 
simplicity with having a helper option for the sockets api that starts 
the other process. kind of like the bridge-helper but a process that 
stays running as long as the netdev is around. this would allow easy 
development of whatever networking methods people would want to 
experiment with. i briefly looked at the code to see how this could 
potentially be implemented but haven't started writing any code.

> Obviously, this could also be done with the normal linux tools at the
> tun/tap layer too.
>
> I think we should resist adding a bunch of stuff to the networking layer
> just because we can.  Otherwise we'll end up reinventing the Linux
> networking layer in QEMU.

definitely a valid point. with the linux 3.7 kernel getting a VXLAN 
implementation, a guest could use a tap device connected to a linux 
bridge which also has a VXLAN interface. this would keep all the 
processing in the kernel and doesn't re-invent the wheel. it still 
requires escalated privileges to configure the networking in the host 
which i'm trying to avoid (stupid misguided security monkey that is 
bugging me). so trade-offs both ways and when i wrote the original patch 
there wasn't anyone even talking about a VXLAN implementation in the 
linux kernel.

mike