[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH-updated] qemu/net: add raw backend
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] Re: [PATCH-updated] qemu/net: add raw backend |
Date: |
Wed, 14 Oct 2009 17:58:53 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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.
[Qemu-devel] Re: [PATCH-updated] qemu/net: add raw backend, Michael S. Tsirkin, 2009/10/14
[Qemu-devel] Re: [PATCH-updated] qemu/net: add raw backend, Michael S. Tsirkin, 2009/10/14