qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Two taps, same IP?
Date: Tue, 15 Jul 2008 20:44:39 -0500	[thread overview]
Message-ID: <487D5287.1080707@codemonkey.ws> (raw)
In-Reply-To: <487D510C.4070106@quinthar.com>

David Barrett wrote:
> 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

You need to pass a unique mac address for each guest.  You're probably 
getting mac address collisions.

Regards,

Anthony Liguori

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

  reply	other threads:[~2008-07-16  1:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-16  1:38 [Qemu-devel] Two taps, same IP? David Barrett
2008-07-16  1:44 ` Anthony Liguori [this message]
2008-07-16  2:11   ` David Barrett
2008-07-16  3:04     ` Erik de Castro Lopo
2008-07-16 13:51     ` Anthony Liguori
2008-07-16  3:05 ` Erik de Castro Lopo
2008-07-16  4:25   ` David Barrett

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=487D5287.1080707@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --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).