Re: [Qemu-devel] Connecting vde and LAN

[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 could, but it seems that short of kernel level bridging there is no way to
"route" ethernet packets.

> 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.

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.
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).

> 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...
> 

I think this can already be done, without even needing to play with the kernel.
Just set up a tap0 and a tap1. Guests connects to tap1, while tap0 is used by
the host OS (e.g. services are set up to connect to tap0 instead of eth0).
All thats needed is some glue to connect tap0 to tap1 (this can be done
with a userland program) and then vde_pcap can connect eth0 to the tap devices.

(The reason we can glue tap0 and tap1 together, but have a much harder time with
eth0 and tap0, is because when we write to tap0, the host sees it. We can't
write to eth0 directly but (ultimately) have to use a packet socket, which
means the host won't see it.)

This isn't much better than using kernel bridging.

> 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.
> 

If we're going to be poking around in the kernel anyways, it'd be a lot easier
to

a) fix packet sockets so that the host OS will see packets sent there (or
if this breaks things too badly, create a new type of socket to the same
effect)

or

b) alter the bridging code so that when we create a bridge, its named
eth0 instead of br0.

If we had a), then vde_pcap would "just work" - there'd be no need to fiddle
with faking things on tap devices or etc.

> So this is a summary of what I think we should try to achieve (sorted by 
> priority):


Most of these are my goals as well (except I don't mind having to run a bit of
glue in a startup script).

> -provide Ethernet-layer access from the Guest to the LAN (so that it's 
> transparent for IP traffic)

vde_pcap does this already.

> -allow using a LAN-wide DHCP server for the Guest

vde_pcap does this already, unless the DHCP server is running on the host.

> -the host should be able to set up his LAN interface over the LAN-wide 
> DHCP server.

vde_pcap doesn't affect this. It should work.

> -the host networking still works as before (at least on the layers above 
> Ethernet)

vde_pcap doesn't affect this. It should work, unless we're talking about
guest->host communication at the packet level. This is the main hurdle I'm
trying to tear down.

> -the whole thing is easy to set up

Define "easy". :-D Well, the whole thing can be set up in a script - all the
tricky stuff is done in the code of vde_pcap and friends, so from a users
point of view they're just running a couple of commands.

> -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).

This is true for vde_pcap already. Also, tap devices can be created whenever
we want.

> 
> 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
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.