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: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH] net: add raw backend
Date: Tue, 7 Jul 2009 15:57:39 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Or Gerlitz wrote:
> Now, before going into libpcap vs. packet socket, I'd be happy if you or 
> Antony can help me understand the comments that with this approach guest 
> <--> host communication is impossible. AFAIK, the only packet sent by 
> Qemu is gratuitous ARP after migration, but it doesn't fall into guest 
> <--> host communication over the NIC/vlan/back-end gang, so I don't see 
> what is this traffic which is impossible with the bridge-less approach.

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.

Unfortunately, bridging is a pain to set up, if your host has any
complicated or automatic network configuration already.

For example, it's impossible to make it work with NetworkManager,
which manages a mobile host's wired and wireless network interfaces.
(I want to use lots of VMs on my laptop, and I want them to appear on
the same network as whatever my host is connecting to automatically.
Bridging - the way Linux does it - makes that difficult).

The main advantage of pcap/packet is you don't need potentially
difficult to configure bridges set up on the host network especially
to support VMs.  pcap/packet just works - as long as you don't need
any host<->guest or guest<->guest communication.

The main advantage of bridging is you get simple, complete
host<->guest and guest<->guest communication - (except the host can
firewall them).

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.  (Maybe those are different ways of saying the same thing.)

> Also, if for some reason one need to communicate from the guest to the 
> host the -net raw can instructed to run over a veth Linux interface 
> couple which are connected to a bridge.

But you might as well use a tap interface connected to a bridge instead.

tap or veth+packet are virtually equivalent, and they both have the
same bridging configuration problems if the host network is interesting.

-- Jamie




reply via email to

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