Bug 182135 - Networking not working in guest
Summary: Networking not working in guest
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
(Show other bugs)
Version: 5
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Rik van Riel
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-20 18:38 UTC by Brian Wheeler
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-20 21:04:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xend.log (7.53 KB, text/plain)
2006-02-20 18:38 UTC, Brian Wheeler
no flags Details

Description Brian Wheeler 2006-02-20 18:38:59 UTC
Description of problem:
Trying to use xenguest-install.py to install fedora core 5 test 3 into a guest
instance fails because the network isn't functional.

Version-Release number of selected component (if applicable):
kernel-xen-hypervisor-2.6.15-1.1955_FC5
xen-3.0.1-0.20060208.fc5.2


How reproducible:
Every time, including in FC5t2 and earlier

Steps to Reproduce:
1. Install FC5t3 as normal
2. install Xen package later (though it shouldn't matter)
3. reboot into hypervisor
4. resize main OS size with "xm mem-set Domain-0 192"
5. flush the IP tables with "iptables -F"
6. run xenguest-install.py with ftp url for installation (I'm using
ftp://ftp.ussg.indiana.edu/pub/linux/fedora/linux/core/test/4.92/i386/os This is
the same URL I used for the base install!)
7. answer english, us keyboard, and DHCP for networking.
8. wait for DHCP address.
9. wait wait wait
10. Get failed to connect to FTP server
  
Actual results:
FTP fails to connect (HTTP too)

Expected results:
Installation should begin

Additional info:
Here's the network information which may be important:
* dom0's IP is from DHCP, on a public network (i.e. its not 192.168 or 10.)
* dom0's eth0 has this network address
* dom0's peth0 has no IP address (hw addr is FE:FF:FF:FF:FF:FF)
* dom0's veth[1234567] are all not up and have no hw address
* while the domU is running, here's the output for the vif's (and bridge) in
question:
vif0.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:857 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12998 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:90235 (88.1 KiB)  TX bytes:4588129 (4.3 MiB)
vif1.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:39 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7773 errors:0 dropped:217 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3916 (3.8 KiB)  TX bytes:863819 (843.5 KiB)

xenbr0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          inet6 addr: 2001:18e8:2:32:fcff:ffff:feff:ffff/64 Scope:Global
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9670 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:909851 (888.5 KiB)  TX bytes:1790 (1.7 KiB)

* iptables-save data looks like:
# Generated by iptables-save v1.3.5 on Mon Feb 20 13:37:35 2006
*nat
:PREROUTING ACCEPT [5312:863526]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Mon Feb 20 13:37:35 2006
# Generated by iptables-save v1.3.5 on Mon Feb 20 13:37:35 2006
*filter
:INPUT ACCEPT [3849:3532442]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2602:2182998]
:RH-Firewall-1-INPUT - [0:0]
-A FORWARD -m physdev  --physdev-in vif1.0 -j ACCEPT
COMMIT
# Completed on Mon Feb 20 13:37:35 2006

So it looks like the dropped packets on vif1.0 are a symptom, but I cannot tell
what's causing it.

Messages from /var/log/messages
---------------
Feb 20 13:15:03 zoidberg kernel: Bridge firewalling registered
Feb 20 13:15:06 zoidberg NET[2049]: /sbin/dhclient-script : updated /etc/resolv.conf
Feb 20 13:15:06 zoidberg kernel: device vif0.0 entered promiscuous mode
Feb 20 13:15:06 zoidberg kernel: xenbr0: port 1(vif0.0) entering learning state
Feb 20 13:15:06 zoidberg kernel: xenbr0: topology change detected, propagating
Feb 20 13:15:06 zoidberg kernel: xenbr0: port 1(vif0.0) entering forwarding state
Feb 20 13:15:06 zoidberg kernel: ACPI: PCI Interrupt 0000:01:0c.0[A] -> Link
[LNKC] -> GSI 5 (level, low) -> IRQ 5
Feb 20 13:15:06 zoidberg kernel: peth0: Setting promiscuous mode.
Feb 20 13:15:06 zoidberg kernel: device peth0 entered promiscuous mode
Feb 20 13:15:07 zoidberg kernel: xenbr0: port 2(peth0) entering learning state
Feb 20 13:15:07 zoidberg kernel: xenbr0: topology change detected, propagating
Feb 20 13:15:07 zoidberg kernel: xenbr0: port 2(peth0) entering forwarding
stateFeb 20 13:15:08 zoidberg dhclient: DHCPREQUEST on eth0 to 255.255.255.255
port 67
Feb 20 13:15:08 zoidberg dhclient: DHCPACK from 129.79.32.254
Feb 20 13:15:08 zoidberg NET[2229]: /sbin/dhclient-script : updated /etc/resolv.conf
Feb 20 13:15:09 zoidberg dhclient: bound to 129.79.32.152 -- renewal in 11260
seconds.
Feb 20 13:15:27 zoidberg gconfd (root-2449): starting (version 2.13.5), pid 2449
user 'root'
Feb 20 13:15:27 zoidberg gconfd (root-2449): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration
source at position 0
Feb 20 13:15:27 zoidberg gconfd (root-2449): Resolved address
"xml:readwrite:/root/.gconf" to a writable configuration source at position 1
Feb 20 13:15:27 zoidberg gconfd (root-2449): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source
at position 2
Feb 20 13:15:30 zoidberg gconfd (root-2449): Resolved address
"xml:readwrite:/root/.gconf" to a writable configuration source at position 0
Feb 20 13:18:07 zoidberg kernel: device vif1.0 entered promiscuous mode
Feb 20 13:18:07 zoidberg kernel: xenbr0: port 3(vif1.0) entering learning state
Feb 20 13:18:07 zoidberg kernel: xenbr0: topology change detected, propagating
Feb 20 13:18:07 zoidberg kernel: xenbr0: port 3(vif1.0) entering forwarding state
Feb 20 13:18:07 zoidberg kernel: xenbr0: port 3(vif1.0) entering learning state
Feb 20 13:18:07 zoidberg kernel: xenbr0: topology change detected, propagating
Feb 20 13:18:07 zoidberg kernel: xenbr0: port 3(vif1.0) entering forwarding state
Feb 20 13:18:08 zoidberg kernel: loop: loaded (max 8 devices)
-------------------------

Comment 1 Brian Wheeler 2006-02-20 18:38:59 UTC
Created attachment 124895 [details]
xend.log

Comment 2 Jeremy Katz 2006-02-20 20:01:50 UTC
Is the DHCP server that hands out an IP to your machine configured so that it
will hand out IPs to the guests as well?  The default network config is
bridging, so will basically be as though the guests were on the public net as
well.  You can change this by modifying /etc/xen/xend-config.sxp

Comment 3 Brian Wheeler 2006-02-20 20:27:33 UTC
Yes, that seems to be it.  I supplied a static IP and it was ok.  This might be
a good one to put in the wiki page.

Thanks!

Comment 4 Jeremy Katz 2006-02-20 21:04:55 UTC
It's actually covered a bit in the users' guide, but I've added a snippet to the
wiki as well.


Note You need to log in before you can comment on or make changes to this bug.