From: Oliver Gerlich <olig9@gmx.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Connecting vde and LAN
Date: Thu, 11 Aug 2005 18:24:51 +0200 [thread overview]
Message-ID: <42FB7BD3.60505@gmx.de> (raw)
In-Reply-To: <Pine.LNX.4.61.0508111623330.7988@filer.marasystems.com>
Henrik Nordstrom wrote:
> On Wed, 10 Aug 2005, Jim C. Brown wrote:
>
[...]
> The above should work for most situations where the host is a just a
> host on the LAN, but if the host is a LAN server for broadcast Ethernet
> protocols such as DHCP some additional configuration of each such
> service may be required to also listen on the tap0 device if the guest
> should be able to use these services. Quite likely also applies to some
> other protocols such as IPX or AppleTalk as these frames almost
> certainly will be ignored by the host on the tap0 device unless
> configured proper for each protocol.
Couldn't we avoid these incompatibilities if we would route packets only
on the Ethernet level? If the Qemu networking setup on the host involves
IP addresses or such things, we're already on the wrong OSI layer I think...
I'm not very experienced in networking, but IMHO the network should be
set up like this:
(eth0 on Host OS)
/
( LAN ) <----> (real eth0) <-> VDE
\
(NIC on Guest OS)
(substitute eth0 by the LAN network interface of your computer)
So VDE acts as an Ethernet switch between LAN, Host OS and Guest OS.
This would limit VDE action to the Ethernet layer.
To connect to the LAN, VDE would use the real (physical) eth0 of the
host system. When packets arrive from Host OS or Guest OS, they would be
sent to the LAN with the source MAC addresses preserved.
The connection to the Qemu guests should be easy as well (every guest
has a MAC address anyway).
The host part is really difficult: VDE would have to provide a "faked"
eth0 to the host OS, so that programs on the host could still use eth0
as Ethernet interface. This faked eth0 would be connected to VDE just
like the Guests are.
I guess this means that VDE would have to provide a kernel-layer
component which grabs the packets from eth0 and provides the faked eth0
for the Host OS...
Although IMHO this is the cleanest way to set up networking, it's
probably not possible to implement this :-) But maybe we could use it as
a starting point for the networking.
So this is a summary of what I think we should try to achieve (sorted by
priority):
-provide Ethernet-layer access from the Guest to the LAN (so that it's
transparent for IP traffic)
-allow using a LAN-wide DHCP server for the Guest
-the host should be able to set up his LAN interface over the LAN-wide
DHCP server.
-the host networking still works as before (at least on the layers above
Ethernet)
-the whole thing is easy to set up
-the whole thing can be started by any user at any time (so it's not
started at boot time, but whenever a user starts Qemu).
If we could achieve all of these requirements, it would be fantastic :-)
But maybe we could at least reach some of them.
What are your comments on this?
Regards,
Oliver Gerlich
next prev parent reply other threads:[~2005-08-11 16:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-10 12:27 [Qemu-devel] Connecting vde and LAN Oliver Gerlich
2005-07-10 16:42 ` Henrik Nordstrom
2005-07-10 17:37 ` Jim C. Brown
2005-07-10 18:23 ` Oliver Gerlich
2005-07-10 18:58 ` Jim C. Brown
2005-07-11 2:21 ` Henrik Nordstrom
2005-07-11 2:33 ` Jim C. Brown
2005-07-11 7:50 ` Henrik Nordstrom
2005-07-11 15:02 ` Jim C. Brown
2005-07-11 23:01 ` Jim C. Brown
2005-07-12 2:49 ` Henrik Nordstrom
2005-07-12 22:25 ` Jim C. Brown
2005-08-04 10:14 ` Henrik Nordstrom
2005-08-05 16:54 ` Jim C. Brown
2005-08-10 19:07 ` Jim C. Brown
2005-08-11 14:56 ` Henrik Nordstrom
2005-08-11 16:24 ` Oliver Gerlich [this message]
2005-08-11 16:56 ` Jim C. Brown
2005-08-12 10:02 ` Henrik Nordstrom
2005-08-12 18:07 ` Jim C. Brown
2005-08-11 17:00 ` Paul Brook
2005-08-12 0:11 ` Herbert Poetzl
2005-08-12 9:53 ` Henrik Nordstrom
2005-07-10 17:48 ` Oliver Gerlich
2005-07-11 1:36 ` Henrik Nordstrom
2005-07-12 19:43 ` Ross Kendall Axe
2005-07-12 20:31 ` Oliver Gerlich
2005-07-13 3:02 ` Ross Kendall Axe
2005-07-10 18:27 ` Bakul Shah
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=42FB7BD3.60505@gmx.de \
--to=olig9@gmx.de \
--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).