Bug 182135 - Networking not working in guest
Networking not working in guest
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rik van Riel
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-20 13:38 EST by Brian Wheeler
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-20 16:04:55 EST
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 13:38 EST, Brian Wheeler
no flags Details

  None (edit)
Description Brian Wheeler 2006-02-20 13:38:59 EST
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 13:38:59 EST
Created attachment 124895 [details]
xend.log
Comment 2 Jeremy Katz 2006-02-20 15:01:50 EST
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 15:27:33 EST
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 16:04:55 EST
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.