Re: [Qemu-devel] Connecting vde and LAN

2005-08-12 Thread Henrik Nordstrom
On Thu, 11 Aug 2005, Oliver Gerlich wrote: 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... From what I can tell there

Re: [Qemu-devel] Connecting vde and LAN

2005-08-12 Thread Henrik Nordstrom
On Thu, 11 Aug 2005, Jim C. Brown wrote: Incidently, if you have eth0 and eth1, and both are connected to the same LAN, then it works. Just set up vde_packet/pcacp on eth1, then packed tp the host from the VDE will be sent out over eth1 and recieved back in eth0. Right. Just don't set an IP

Re: [Qemu-devel] Connecting vde and LAN

2005-08-12 Thread Jim C. Brown
On Fri, Aug 12, 2005 at 12:02:46PM +0200, Henrik Nordstrom wrote: This solves the problem quite nicely, and it is probably the simplest to implement, but requires changing the hardware. I'm trying to figure out how to achieve the same effect with eth0 and tap0 (as opposed to eth0 and eth1).

Re: [Qemu-devel] Connecting vde and LAN

2005-08-11 Thread Henrik Nordstrom
On Wed, 10 Aug 2005, Jim C. Brown wrote: I was thinking that perhaps vde_packet could be modified to use a tap device (for example tap0). Since the guests can't communicate to the address thats on tap0, it doesn't matter what address it gets - the host address of tap0 and the ip addresses of

Re: [Qemu-devel] Connecting vde and LAN

2005-08-11 Thread Oliver Gerlich
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

Re: [Qemu-devel] Connecting vde and LAN

2005-08-11 Thread Jim C. Brown
On Thu, Aug 11, 2005 at 06:24:51PM +0200, Oliver Gerlich wrote: 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... We

Re: [Qemu-devel] Connecting vde and LAN

2005-08-11 Thread Herbert Poetzl
On Thu, Aug 11, 2005 at 06:00:12PM +0100, Paul Brook wrote: 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... You can do all this with the standard linux tools. Something like the

Re: [Qemu-devel] Connecting vde and LAN

2005-08-04 Thread Henrik Nordstrom
On Tue, 12 Jul 2005, Jim C. Brown wrote: I just tried this with libnet 1.1 (1.1.2.1 to be specific), and it doesn't seem to work. Pings do not go through. I only handled the vde - host case though, do I need to do anything special for host - vde packets? Did you fake the ARP response to the

Re: [Qemu-devel] Connecting vde and LAN

2005-07-12 Thread Ross Kendall Axe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver Gerlich wrote: The problem is that I start vde_switch and the bridging not at boot, but when I want to run Qemu. So then I have to restart Samba to bind to to br0 instead of eth0. Not so much of a problem though... Only I don't know what

Re: [Qemu-devel] Connecting vde and LAN

2005-07-11 Thread Henrik Nordstrom
On Sun, 10 Jul 2005, Jim C. Brown wrote: Yes, but if one was running multiple qemu guests, it would be cleaner to implement this thru vde_switch instead of in qemu directly. That way eth0 is intercepted by only a single process. (Also no worries about having permissions to intercept packets and

Re: [Qemu-devel] Connecting vde and LAN

2005-07-11 Thread Jim C. Brown
On Mon, Jul 11, 2005 at 09:50:11AM +0200, Henrik Nordstrom wrote: On Sun, 10 Jul 2005, Jim C. Brown wrote: I didn't mean to implement this in qemu directly, but rather in a helper similar to vdeq, but the primary method should be via vde_switch. Having this shortcut helper is a future

Re: [Qemu-devel] Connecting vde and LAN

2005-07-11 Thread Jim C. Brown
On Mon, Jul 11, 2005 at 11:02:04AM -0400, Jim C. Brown wrote: b) can't talk to the host itself. This is due to the packets going directly to the wire and never really seen by the host stack. Not sure yet if there is an easy way out, but I suppose it may be possible to set up a dummy

Re: [Qemu-devel] Connecting vde and LAN

2005-07-11 Thread Henrik Nordstrom
On Mon, 11 Jul 2005, Jim C. Brown wrote: I tried using libnet 1.0 to send the packets, but that did not help. Also tried libnet 1.1, that actually allowed the host to be pinged by the guest - part of the time. It also caused pings on the same lan (from the guest) to fail as well sometimes, so

[Qemu-devel] Connecting vde and LAN

2005-07-10 Thread Oliver Gerlich
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, what is the best solution to connect the vde switch to my real LAN so that Qemu guests get IPs from my LAN-wide DHCP server? So far I've experimented with bridging tap0 and eth0 so that the Qemu guests are transparently on my LAN and get IPs

Re: [Qemu-devel] Connecting vde and LAN

2005-07-10 Thread Henrik Nordstrom
On Sun, 10 Jul 2005, Oliver Gerlich wrote: what is the best solution to connect the vde switch to my real LAN so that Qemu guests get IPs from my LAN-wide DHCP server? bridgeing of your ethernet interface and the TAP interface connecting to vde is undoubtly the best if you want to provide

Re: [Qemu-devel] Connecting vde and LAN

2005-07-10 Thread Jim C. Brown
On Sun, Jul 10, 2005 at 08:23:17PM +0200, Oliver Gerlich wrote: The best solution is to use a vde_switch with libpcap and libnet. This allows intercepting packets meant for the guests (via libnet) and forwarding them thru vde. libpcap allows for packets in vde to be passed on to the

Re: [Qemu-devel] Connecting vde and LAN

2005-07-10 Thread Jim C. Brown
On Mon, Jul 11, 2005 at 04:21:31AM +0200, Henrik Nordstrom wrote: On Sun, 10 Jul 2005, Jim C. Brown wrote: The best solution is to use a vde_switch with libpcap and libnet. This allows intercepting packets meant for the guests (via libnet) and forwarding them thru vde. Interesting