On 11/27/2012 07:24 AM, Anthony Liguori wrote:
Stefan Hajnoczi <stefa...@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
