From: Jamie Lokier <jamie@shareable.org>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Alex Williamson <alex.williamson@hp.com>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 6/7] virtio-net: Add new RX filter controls
Date: Tue, 9 Jun 2009 16:00:13 +0100 [thread overview]
Message-ID: <20090609150012.GA3921@shareable.org> (raw)
In-Reply-To: <20090609095701.GC1480@redhat.com>
Daniel P. Berrange wrote:
> Personally I'd just say the bridge config task is the management tool's
> problem to deal with. A mgmt tool UI shouldn't really need to expose
> the raw details of physical NICs, bond devices, VLAN devices & bridge
> devices to the user. Instead allow them to say 'create a network sharing
> two physical NICs on VLAN 53', and then have it automagically setup the
> neccessary individal devices behind the scenes.
That's a nice idea, but it depends so intimately on the host's network
configuration, that it doesn't work in practice (in my experince),
except in some rather fixed configurations.
The problem is: when you attach a bridge device, then all the host's
IP configuration has to be done on the bridge device instead of the
host's network interfaces.
That means either:
- Host's network configuration (outside the management tool) must
create bridges in advance (with one port) _just_ so that VM
management can attach to the bridge. It's hardly transparent.
Doesn't work at all with NetworkManager or any ordinary host
network configurations, for example. And you have to do it in
advance, not when starting VMs.
- Or, the VM management tool must create bridges when VMs are
started, and then copy the IP configuration from the host
network interface to the bridge, and it must somehow trick the
host's DHCP client to moving to the bridge interface, etc. This
doesn't work with NetworkManager either.
Quite possibly it's a mess because of the way Linux does bridging, but
still it is.
I haven't found any solution which works on a laptop running
NetworkManager or other automatic network binding service.
For servers with static IPs and simple network configuration it is
easier, and of course a VM management tool can always handle specific
cases like that, if told to. But even on servers, I find if they have
a complex host network configuration (e.g. policy routing tables),
adding bridges for the VMs is not something that can be done
automatically.
Ideally, there would be a way to add a "bridge for VM" which hangs off
the edge of the host's networking, instead of disruptively having to
be in the middle.
The pcap interface is close to that for ease of configurability, but a
bridge would behave better, especially with multiple VMs, and maybe
perform better.
-- Jamie
next prev parent reply other threads:[~2009-06-09 15:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 20:46 [Qemu-devel] [PATCH 0/7] virtio-net: Filter cleanup/improvements Alex Williamson
2009-06-05 20:46 ` [Qemu-devel] [PATCH 1/7] virtio-net: Add version_id 7 placeholder for vnet header support Alex Williamson
2009-06-05 20:46 ` [Qemu-devel] [PATCH 2/7] virtio-net: Use a byte to store RX mode flags Alex Williamson
2009-06-05 20:47 ` [Qemu-devel] [PATCH 3/7] virtio-net: reorganize receive_filter() Alex Williamson
2009-06-05 20:47 ` [Qemu-devel] [PATCH 4/7] virtio-net: Fix MAC filter overflow handling Alex Williamson
2009-06-05 20:47 ` [Qemu-devel] [PATCH 5/7] virtio-net: MAC filter optimization Alex Williamson
2009-06-05 20:47 ` [Qemu-devel] [PATCH 6/7] virtio-net: Add new RX filter controls Alex Williamson
2009-06-06 20:48 ` Michael S. Tsirkin
2009-06-08 19:01 ` Alex Williamson
2009-06-08 19:18 ` Anthony Liguori
2009-06-08 19:29 ` Daniel P. Berrange
2009-06-08 21:03 ` Anthony Liguori
2009-06-09 9:57 ` Daniel P. Berrange
2009-06-09 15:00 ` Jamie Lokier [this message]
2009-06-09 15:42 ` [Qemu-devel] " Jan Kiszka
2009-06-09 23:50 ` Jamie Lokier
2009-06-10 8:46 ` Michael S. Tsirkin
2009-06-10 8:58 ` Jan Kiszka
2009-06-10 9:07 ` Michael S. Tsirkin
2009-06-10 9:13 ` Gleb Natapov
2009-06-10 9:17 ` Michael S. Tsirkin
2009-06-10 9:22 ` Gleb Natapov
2009-06-10 9:35 ` Michael S. Tsirkin
2009-06-08 20:18 ` [Qemu-devel] " Alex Williamson
2009-06-05 20:47 ` [Qemu-devel] [PATCH 7/7] virtio-net: Increase filter and control limits Alex Williamson
2009-06-06 20:44 ` Michael S. Tsirkin
2009-06-08 18:49 ` Alex Williamson
2009-06-09 19:25 ` [Qemu-devel] [PATCH 0/7] virtio-net: Filter cleanup/improvements Mark McLoughlin
2009-06-09 21:08 ` Alex Williamson
2009-06-10 6:51 ` Rusty Russell
2009-06-10 20:43 ` Alex Williamson
2009-06-12 17:07 ` Mark McLoughlin
2009-06-12 19:19 ` Alex Williamson
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=20090609150012.GA3921@shareable.org \
--to=jamie@shareable.org \
--cc=alex.williamson@hp.com \
--cc=berrange@redhat.com \
--cc=mst@redhat.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).