From: Jamie Lokier <jamie@shareable.org>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Or Gerlitz <ogerlitz@voltaire.com>,
Arnd Bergmann <arndbergmann@googlemail.com>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH-updated] qemu/net: add raw backend
Date: Wed, 14 Oct 2009 16:14:06 +0100 [thread overview]
Message-ID: <20091014151406.GA17062@shareable.org> (raw)
In-Reply-To: <4AD5E449.9070301@codemonkey.ws>
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
next prev parent reply other threads:[~2009-10-14 15:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-14 14:34 [Qemu-devel] [PATCH-updated] qemu/net: add raw backend Or Gerlitz
2009-10-14 14:46 ` [Qemu-devel] " Anthony Liguori
2009-10-14 15:14 ` Jamie Lokier [this message]
2009-10-14 15:58 ` Anthony Liguori
2009-10-14 16:14 ` Michael S. Tsirkin
2009-10-14 16:54 ` Jamie Lokier
2009-10-14 17:20 ` Michael S. Tsirkin
2009-10-14 18:36 ` Anthony Liguori
2009-10-14 19:37 ` Michael S. Tsirkin
2009-10-15 7:48 ` Or Gerlitz
2009-10-14 15:58 ` Michael S. Tsirkin
2009-10-14 15:24 ` Michael S. Tsirkin
2009-10-14 15:33 ` Gleb Natapov
2009-10-15 7:29 ` Or Gerlitz
2009-10-15 7:44 ` Gleb Natapov
2009-10-15 7:50 ` Or Gerlitz
2009-10-14 16:20 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091014151406.GA17062@shareable.org \
--to=jamie@shareable.org \
--cc=anthony@codemonkey.ws \
--cc=arndbergmann@googlemail.com \
--cc=mst@redhat.com \
--cc=ogerlitz@voltaire.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).