Stefan Hajnoczi <stefa...@gmail.com> writes: > On Mon, Nov 26, 2012 at 6:19 PM, Mike Lovell <m...@dev-zero.net> wrote: >> i think it does still make sense to implement it in QEMU. there isn't a >> problem with multiple processes using the same multicast address. the >> net_socket_mcast_create function in socket.c already sets the >> IP_MULTICAST_LOOP option which makes it so packets get looped back and also >> delivered to processes on the same host. that is why there is a check in >> qdes_receive to see if the sender is the localAddr and drop it if it is. the >> big advantage i see to implementing VXLAN inside QEMU is that it can be done >> without any escalated privileges and without reconfiguring the hosts network >> configuration. > > 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? 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. Regards, Anthony Liguori > > Stefan
