WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

[Xen-users] network issue, RHEL4, lack of peth0/peth1 device

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] network issue, RHEL4, lack of peth0/peth1 device
From: Richard <richard@xxxxxxxxxxxxxxx>
Date: Thu, 23 Nov 2006 16:54:12 +1300
Delivery-date: Wed, 22 Nov 2006 19:54:35 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
Hi! I'm not new to Xen but I'm new to this list. I'm having a truely bizarre 
problem with Xen bridged networking at the moment. This is a new install, on 
RHEL4. The symptom is that any domU set up simply fails to talk to anything 
else. It's there, and running, and it has an ethernet device, but there's never 
any response.

After digging through the system for a while and comparing it to another system 
I have that works, I discovered that the bridge appears to only be partially 
set up on boot. Specifically, it's empty, and the pethX (in my case peth1) 
device is missing entirely.

I have dredged through the network-bridge script and run through as much of it 
as I can in my head, it *seems* like the situation I'm encountering should be 
impossible unless something is failing in an odd manner in the middle of the 
script. I can't play around too extensively, the system is thousands of miles 
away from me and has no remote console or friendly hands nearby.

Has anyone heard of anything like this? I know at least one other person has 
encountered it, my symptoms match those described by Greg Cymbalski on Tue, 7 
Mar 2006 12:33:24 on this list.

All applicable information follows.

Xen: 3.0.3 RPM version from xensource, kernel 2.6.16.29-xen_3.0.3.0
Dom0: RHEL4.4 fresh install, LVM
Hardware: 2xDual Core Xeon 2ghz, 2gb ram, 250gb SATA (mirrored)
Network: eth1 is the only active (and default) network device

xend-config.sxp:

(xend-http-server yes)
(xend-relocation-server yes)
(xend-port            8000)
(xend-relocation-port 8002)
(xend-address localhost)
(xend-relocation-address 'localhost')
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
(network-script network-bridge)
(vif-script vif-bridge)
(dom0-min-mem 196)
(dom0-cpus 0)

xm_core1:

kernel  = '/boot/vmlinuz-2.6-xen'
ramdisk = '/boot/initrd-2.6-xen.img'
memory  = '1024'
cpus = "0,1"
vcpus = 2
root    = '/dev/sda2 ro'
disk = ['phy:vg/s1_swap,sda1,w', 'phy:vg/s1_root,sda2,w', 
'phy:vg/s1_var,sda3,w', 'phy:vg/s1_home,sda4,w']
name    = 'core1'
vif  = [ 'ip=XXX.XX.XX.XXX,bridge=xenbr1' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

# ip link
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: vif0.0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: vif0.1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
5: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
6: vif0.2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
7: veth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8: vif0.3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
9: veth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
10: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:13:72:f8:2a:b4 brd ff:ff:ff:ff:ff:ff
11: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:13:72:f8:2a:b2 brd ff:ff:ff:ff:ff:ff
12: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
13: xenbr1: <BROADCAST,NOARP,UP> mtu 1500 qdisc noqueue
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff


#
# Before xm_core1 startup
#

# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.000000000000       no               can't get port info: 
Function not implemented

* The "can't get port info" message appears to be what happens when the bridge 
is empty, when I start up xm-core1 it contains one vif


# iptables -L -v -n
Chain INPUT (policy ACCEPT 46 packets, 3352 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 27 packets, 3676 bytes)
 pkts bytes target     prot opt in     out     source               destination


#
# After xm_core1 startup
#

# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              vif1.0

# iptables -L -v -n
Chain INPUT (policy ACCEPT 109 packets, 7940 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       XXX.XX.XX.XXX        0.0.0.0/0   
        PHYSDEV match --physdev-in vif1.0
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0   
        PHYSDEV match --physdev-in vif1.0 udp spt:68 dpt:67

Chain OUTPUT (policy ACCEPT 64 packets, 8352 bytes)
 pkts bytes target     prot opt in     out     source               destination

-- 
Richard Clark,
Analysis and Design,
Red Spider Ltd.
(+64) 021 478 219

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-users] network issue, RHEL4, lack of peth0/peth1 device, Richard <=