qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jamie Lokier
Subject: Re: [Qemu-devel] Re: [PATCH-updated] qemu/net: add raw backend
Date: Wed, 14 Oct 2009 16:14:06 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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.

Neither tap nor pcap/raw works particularly well except in static IP
configurations, 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




reply via email to

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