All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Gerlich <olig9@gmx.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] bug reports and suggestions
Date: Mon, 08 May 2006 19:05:19 +0200	[thread overview]
Message-ID: <445F7A4F.1080007@gmx.de> (raw)
In-Reply-To: <20060508155851.GB15522@jbrown.mylinuxbox.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim C. Brown schrieb:
> On Sat, May 06, 2006 at 01:12:50AM +0200, Oliver Gerlich wrote:
> 
>>Don Kitchen schrieb:
>>
>>>Next, it seems the *one* thing QEMU lacks that you-know-who does correctly
>>>is networking, specifically bridged mode. I know about creating a tap device
>>>and sticking it into a bridge (really hasn't worked for me, but that's the
>>>subject for a different day.) I realize that it's a complicated issue
>>>requiring kernel modules, etc, and exponentially more complicated with
>>>cross platform, but I wonder if anyone has considered trying to tie into
>>>the vmware-player's kernel modules and use them? There has to be some sort
>>>of de-facto API for interaction between the modules and the player. Too
>>>rife with IP problems?
>>
>>Someone wrote a kernel module some months ago which exposes some special
>>kernel function via /proc ... IIUC this was intended to allow easier
>>networking... Does anyone know more about it (or did anyone understand
>>my confusing description ;) ?
> 
> 
> I'm the author.
> 
> It is called vde-inject, and it requires vdeqemu to work atm (though adding
> native support in qemu itself is trivial).

Thanks! That's the module I meant :)

> Currently I'm working on a version that doesn't require a kernel module to
> do this - it will have the limitation of only supporting tcp/ip packets when
> talking between host/guest.

Are you sure that limitation is not too "heavy"? How would eg. UDP, ICMP
or Multicast DNS work with the non-kernel-solution? And wouldn't an
ethernet-level emulation be cleaner and also easier to explain to other
users?

>>Another interesting thing concerning networking: I use a little script
>>to set up a bridge between eth0 and tap0; but I have give the new bridge
>>interface (eg. br0) an IP address and such stuff, because eth0 doesn't
>>work. This is with Linux 2.6, but I read that with Linux 2.4 it was not
>>necessary to configure br0, as eth0 would still be accessible. Does
>>anyone know why this changed? I think it would be much easier if an
>>interface used in a bridge was still usable.
> 
> 
> eth0 is still usable. It is just slightly cleaner to use br0 directly.

This is what I tried:

brctl addbr br0
brctl addif br0 eth0

After this, a ping to the IP of eth0 (192.168.0.10) still worked. But a
ping to the gateway (192.168.0.1) didn't. Running `ifconfig br0 up`
didn't help either. Do you have a hint how to make this work?


Thanks,
Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEX3pLTFOM6DcNJ6cRAsTuAKCvN0b68WV/dFsznXWhv+tfaxvZZgCfdYLp
VKEpNiUYKchHgRswHIL/BGo=
=cTW3
-----END PGP SIGNATURE-----

  reply	other threads:[~2006-05-08 17:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05 21:51 [Qemu-devel] bug reports and suggestions Don Kitchen
2006-05-05 23:12 ` Oliver Gerlich
2006-05-06 23:03   ` [Qemu-devel] " Anthony Liguori
2006-05-07  5:40     ` wangji
2006-05-08 15:58   ` [Qemu-devel] " Jim C. Brown
2006-05-08 17:05     ` Oliver Gerlich [this message]
2006-05-08 17:28       ` Jim C. Brown
2006-05-06 22:55 ` [Qemu-devel] " Anthony Liguori
2006-05-08 16:17 ` [Qemu-devel] " Jim C. Brown

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=445F7A4F.1080007@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.