From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdcDP-0006ky-2P for qemu-devel@nongnu.org; Wed, 28 Nov 2012 02:37:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TdcDJ-0002Xi-MT for qemu-devel@nongnu.org; Wed, 28 Nov 2012 02:37:50 -0500 Received: from 69.169.164.127.provo.static.broadweavenetworks.net ([69.169.164.127]:41279 helo=baldr.dev-zero.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdcDJ-0002VU-Gv for qemu-devel@nongnu.org; Wed, 28 Nov 2012 02:37:45 -0500 Message-ID: <50B5BF56.6010101@dev-zero.net> Date: Wed, 28 Nov 2012 00:37:58 -0700 From: Mike Lovell MIME-Version: 1.0 References: <1340602924-3231-1-git-send-email-mike@dev-zero.net> <50B3A494.3050002@dev-zero.net> <877gp7azt5.fsf@codemonkey.ws> In-Reply-To: <877gp7azt5.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] net: RFC New Socket-Based, Switched Network Backend (QDES) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , qemu-devel On 11/27/2012 07:24 AM, Anthony Liguori wrote: > Stefan Hajnoczi 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