On Mon, Jun 25, 2012 at 7:42 AM, Mike Lovell <m...@dev-zero.net> wrote: > This is what I've been calling QDES or QEMU Distributed Ethernet Switch. I > first had the idea when I was playing with the udp and mcast socket network > backends while exploring how to build a VM infrastructure. I liked the idea of > using the sockets backends cause it doesn't require escalated permissions to > configure and run as well as the ability to talk over IP networks.
Hi Mike, I was just reading the VXLAN spec and Linux code when I realized this is similar to your QDES approach: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d342894c5d2f8c7df194c793ec4059656e09ca31 http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 If you're still hacking on QDES you may be interested. VXLAN is a VLAN mechanism that gets around the 12-bit 802.1Q tag size. In large deployments it may be necessary to have more than 4096 VLANs, this is where VXLAN comes in. It's a tiny header with VXLAN Network ID that encapsulates Ethernet inside UDP: [Outer Ethernet][IP][UDP] [VXLAN] [Inner Ethernet][...] UDP is used as follows: 1. If the host has already learnt an Inner MAC -> Outer IP mapping, then it transmits a unicast UDP packet. 2. Otherwise it transmits a multicast UDP packet. That means all hosts join a multicast group - this enables broadcast similar to what you've done in your patches. Typically traffic from a VM on Host A to another VM on Host B will use unicast UDP because the Inner MAC -> Outer IP mapping has been learnt. I'm not sure if it makes sense to implement VXLAN in QEMU because the multicast UDP socket uses a well-known port. I guess that means multiple QEMUs running on the same host cannot use VXLAN unless they bind to unique IP addresses. At that point we lose the advantage of a pure userspace implementation and might as well use the kernel implementation (or OpenVSwitch) with tap devices. Anyway, it's still interesting and maybe there's a way to solve this. Stefan
