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

[Michael S. Tsirkin]

On Wed, Oct 14, 2009 at 04:14:06PM +0100, Jamie Lokier wrote:
> Anthony Liguori wrote:
> > Or Gerlitz wrote:
> > >Add raw network backend option which uses a packet socket to provide
> > >raw networking access. Once the socket is opened it's bound to a
> > >provided host interface, such that packets received on the interface
> > >are delivered to the VM and packets sent by the VM are sent to the
> > >interface.
> > >
> > >This is functionally similar to the existing pcap network
> > >backend, with the same advantages and problems.
> > >Differences from pcap:
> > >- can get an open socket from the monitor,
> > >  which allows running without NET_ADMIN priviledges
> > >- support iovec sends with writev, saving one data copy
> > >- one less dependency on an external library
> > >- we have access to the underlying file descriptor
> > >  which makes it possible to connect to vhost net
> > >- don't support polling all interfaces, always bind to a specific one
> > >  
> > 
> > Networking is probably the area in qemu that users most frequently 
> > stumble with.  The most common problems are:
> > 
> > 1) slirp does not behave how they think it should (icmp doesn't work, 
> > guest isn't accessable from host)
> > 2) it's difficult to figure out which backend behaves the way they want 
> > (socket vs. vde vs. tap)
> > 3) when they figure out they need tap, tap is difficult to setup 
> 
> Worse, tap is impossible to setup properly with things like
> network-manager.
> 
> > The problem with introducing a raw backend (or a pcap backend) is that 
> > it makes #2 even worse because now a user has to figure out whether they 
> > need raw/pcap or tap.  But most troubling, it introduces another issue:
> > 
> > 4) raw does not behave how they think it should because guest<->host 
> > networking does not work bidirectionally
> 
> I suspect user expectations are quite commonly:
> 
>    - guest<->host networking works
>    - guest<->host's network works, directly or through host NAT
>    - guest IP address is either private (inside the host)
>      or on the same network as the host, according to some switch.
> 
> Imho, there is only one right place to fix this, and it's by adding a
> feature to the host.  Either modifying host packet socket, or
> modifying the tap+bridge combination.

Long term, I agree. The patch is just using available interfaces.

> Neither tap nor pcap/raw works particularly well except in static IP
> configurations,

Why don't they?
I have a dhcp server happily assigning IPs to all my guests with raw.

> and qemu cannot realistically work around the
> host configuration difficulties.
> 
> > So unless there's an extremely compelling reason to have this, I'd 
> > rather not introduce this complexity.  NB, I see this as a problem with 
> > vhost_net too if #4 is also true in that context.
> 
> It'd be great if vhost_net doesn't have the configuration problems of
> tap or pcap/raw.
> If it does have the same problems, it's a natural
> place to fix them.
> I haven't looked at vhost_net yet.
> 
> -- Jamie

vhost_net is just a character device to accelerate virtio.
It currently binds to tap or raw socket and so has the same limitations.
Once "bridge sockets" are available we can bind to that.