qemu-devel
[Top][All Lists]
Advanced

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

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


From: Or Gerlitz
Subject: Re: [Qemu-devel] [PATCH] net: add raw backend
Date: Wed, 08 Jul 2009 17:45:05 +0300
User-agent: Thunderbird 1.5.0.10 (Windows/20070221)

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.





reply via email to

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