From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KIw02-0006jT-79 for qemu-devel@nongnu.org; Tue, 15 Jul 2008 21:40:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KIw01-0006jB-CL for qemu-devel@nongnu.org; Tue, 15 Jul 2008 21:40:09 -0400 Received: from [199.232.76.173] (port=59860 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIw01-0006j8-87 for qemu-devel@nongnu.org; Tue, 15 Jul 2008 21:40:09 -0400 Received: from yx-out-1718.google.com ([74.125.44.155]:3527) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KIw00-0002Mv-Qd for qemu-devel@nongnu.org; Tue, 15 Jul 2008 21:40:09 -0400 Received: by yx-out-1718.google.com with SMTP id 3so1620368yxi.82 for ; Tue, 15 Jul 2008 18:40:08 -0700 (PDT) Message-ID: <487D510C.4070106@quinthar.com> Date: Tue, 15 Jul 2008 18:38:20 -0700 From: David Barrett MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Two taps, same IP? Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org I'm considering a tap-based alternative to the -redir patch I proposed earlier, but I'm just not quite getting how it works. In particular, I'm able to access the webserver on one image just fine, but not the other: wget fails with "Connecting to 172.20.0.3:80... failed: No route to host." Can you explain why and set me straight? Specifically, I have two Debian qemu images (0 and 1), identical in all respects except that image0 and image1 are configured to use static IPs 172.20.0.2 and 172.20.0.3, respectively. I've launched both simultaneously with the following commands: sudo qemu -kernel-kqemu -net nic,vlan=0 -net tap,vlan=0 image0.raw sudo qemu -kernel-kqemu -net nic,vlan=0 -net tap,vlan=0 image1.raw Each image is configured with the following /etc/network/interfaces: auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet static address 172.20.0.2 <--- image1 has: address 172.20.0.3 netmask 255.255.0.0 gateway 172.20.0.1 This creates two tap interfaces (0 and 1) on the Ubuntu host, curiously with the same IP: tap0 Link encap:Ethernet HWaddr 00:ff:84:12:9d:72 inet addr:172.20.0.1 Bcast:172.20.255.255 Mask:255.255.0.0 inet6 addr: fe80::2ff:84ff:fe12:9d72/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:18 errors:0 dropped:0 overruns:0 frame:0 TX packets:36 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:1336 (1.3 KB) TX bytes:4704 (4.5 KB) tap1 Link encap:Ethernet HWaddr 00:ff:af:9a:48:29 inet addr:172.20.0.1 Bcast:172.20.255.255 Mask:255.255.0.0 inet6 addr: fe80::2ff:afff:fe9a:4829/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:24 errors:0 dropped:0 overruns:0 frame:0 TX packets:34 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:1656 (1.6 KB) TX bytes:4664 (4.5 KB) "wget http://172.20.0.2" and "wget http://172.20.0.3" each work fine inside their respective VMs. But each is unable to wget the other's webserver. Furthermore, and most unusual, the host is able to wget image0's webserver fine, but not image1. Specifically, the second wget fails as follows: david@SonOfLappy:/svn/staging$ wget http://172.20.0.3 --18:17:12-- http://172.20.0.3/ => `index.html.1' Connecting to 172.20.0.3:80... failed: No route to host. david@SonOfLappy:/svn/staging$ The error message suggests some sort of routing problem, and the routing table is: david@SonOfLappy:/svn/staging$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 68.28.57.85 * 255.255.255.255 UH 0 0 0 ppp0 172.20.0.0 * 255.255.0.0 U 0 0 0 tap0 172.20.0.0 * 255.255.0.0 U 0 0 0 tap1 default * 0.0.0.0 U 0 0 0 ppp0 david@SonOfLappy:/svn/staging$ However, I'll admit I don't know much about the routing layer and thus I'm not sure how to diagnose beyond that. But it seems very strange to me to have two network interfaces with the same IP. With this in mind, if I shut down image0, the tap0 interface goes away, and now the wget to image1 works fine. Again, this is suggesting there's some kind of conflict where the second tap interface is somehow "blocked" by the first. Anyway, that's as far as I can get. Is this supposed to work and am I doing something wrong? Or am I supposed to do launch the second image with some other kind of command line? Should I manually create my own tap devices before launching either image (and if so, any pointers on how I go about doing that)? (Incidentally, I've tried putting the second image onto a different vlan by replacing both "vlan=0" with "vlan=1" in image1's launch command, but that had no effect -- the results were identical.) Thanks for any tips you can provide! -david