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
>
>
>
next prev parent 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).