Re: [Qemu-devel] [PATCH] net: add raw backend

[Or Gerlitz <ogerlitz@voltaire.com>]

Jamie Lokier wrote:
> The problem is simply what the guest sends goes out on the network and is not looped backed to the host network stack, and vice versa. So if your host is 192.168.1.1 and is running a DNS server (say), and the guest is 192.168.1.2, when the guest sends queries to 192.168.1.1 the host won't see those queries.  Same if you're running an FTP server on the host and the guest wants to connect to it, etc. It also means multiple guests can't see each other, for the same reason. So it's much less useful than bridging, where the guests and host can all see each other and connect to each other.
I wasn't sure to follow if your example refers to the case when 
networking uses the bridge or NAT. If its bridge, then through which 
bridge interface the packet arrives the host stack? say you have a 
bridge whose attached interfaces are tap1(VM1), tap2(VM2) and eth0(NIC), 
in your example did you mean that the host IP address is assigned to the 
bridge interface? or you were referring a NAT based scheme?


> Unfortunately, bridging is a pain to set up, if your host has any complicated or automatic network configuration already.
As you said bridging requires more configuration, but not less important 
the performance (packets per second and cpu utilization) one can get 
with bridge+tap is much lower vs what you get with the raw mode 
approach. All in all, its clear that with this approach VM/VM and 
VM/Host communication would have to get switched either at the NIC (e.g 
SR/IOV capable NICs supporting a virtual bridge) or at an external 
switch and make a U turn. There's a bunch of reasons why people would 
like to do that, among them performance boost, the ability to shape, 
manage and monitor VM/VM traffic in external switches and more.

> It would be really nice to find a way which has the advantages of both.  Either by adding a different bridging mode to Linux, where host interfaces can be configured for IP and the bridge hangs off the host interface, or by a modified tap interface, or by an alternative
> pcap/packet-like interface which forwards packets in a similar way to bridging.  
It seems that this will not yield  the performance improvement we can 
get with going directly to the NIC. But if someone comes up and makes 
such a mode working, it can be merged into qemu as well along with the 
raw mode.

Or.