qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QDES)
Date: Tue, 27 Nov 2012 08:24:54 -0600
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Stefan Hajnoczi <address@hidden> writes:

> On Mon, Nov 26, 2012 at 6:19 PM, Mike Lovell <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]