From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Or Gerlitz <ogerlitz@voltaire.com>,
Arnd Bergmann <arndbergmann@googlemail.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH-updated] qemu/net: add raw backend
Date: Wed, 14 Oct 2009 19:20:40 +0200 [thread overview]
Message-ID: <20091014172040.GB30367@redhat.com> (raw)
In-Reply-To: <20091014165447.GA19784@shareable.org>
On Wed, Oct 14, 2009 at 05:54:47PM +0100, Jamie Lokier wrote:
> Michael S. Tsirkin wrote:
> > > The fact that network manager does work well with bridged interfaces is
> > > a network manager bug.
> >
> > Network manager was just one example.
>
> Even if network manager and all other configuration programs are fixed
> to handle a bridge, it's still quite fiddly to configure them.
>
> I find I have to use
>
> - bridges to an uplink interface for some VMs (guest has IP on same
> network as host, fixed host interfaces, typically in servers)
Another similar setup of interest is when you have dhcp server and want
both VMs and host to get IP from there.
> - bridges attached to changing uplink for some VMs (laptop, where
> the main internet uplink changes between eth0/wlan0/ppp0/bnep0
> according to available signals)
>
> - no bridge at all (just routing tap, used on all sorts of machines)
> for VMs needing to run on host-local IPs and talk to the host,
> and maybe NAT to the internet
>
> - bridges not attached to any host interface, just multiple tap
> interfaces, used to connect guests with host-local IPs that must
> see each other's broadcasts
>
> The corresponding iptables is rather tricky too.
Another issue is that host will often lose networking while you fiddle
with bridge connected to an uplink. So doing this if your only way to
access the box is through the network is tricky.
> > > It's getting fixed so in the near future, tap will satisfy all of
> > > these requirements.
>
> That will be really nice if it does.
>
> -- Jamie
next prev parent reply other threads:[~2009-10-14 17:23 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
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 [this message]
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=20091014172040.GB30367@redhat.com \
--to=mst@redhat.com \
--cc=arndbergmann@googlemail.com \
--cc=jamie@shareable.org \
--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).