Bug 115309

Created attachment 48803 [details]
/var/log/messages

Created attachment 48804 [details]
/var/log/mxen

last entry was a typo. the file is /var/log/xend.log

sorry, I can't attach a hwinfo at the moment, my machine reboots or hangs during
hwinfo :-/

Created attachment 48813 [details]
hwinfo

managed to get a hwinfo...

Micha, do you have SUSEfirewall2 active and use bridging?  
What the SFW2 output in syslog ...  
But I don't see anything in your syslog that points to SFW2 :-( 
But you may not have logging enabled. 
  
Here's what I did to make it work with SFW2: 
FW_DEV_DMZ="eth0 xenbr0 vif0.0"  
and I specifically put a rule into the -custom script:  
FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"  
fw_custom_before_masq() {  
    iptables -A forward_dmz -j ACCEPT -i xenbr0 -o xenbr0  
}  
  
The latter can probably be done by some setting in the normal config file, 
but I find reading plain iptables syntax easier ... 
 
And you need /proc/sys/net/ipv4/ip_forward enabled (aka FW_ROUTE="yes" 
aka IP_FORWARD="yes" in sysctl aka proc.sys.net.ipv4.ip_forward=1 in 
sysctl.conf). 
 
When xend starts in bridge mode, it does a couple of strange things: 
* ifdown eth0 
* Rename eth0 -> peth0 
* Copy MAC address from peth0 to veth0 
* Set peth to NOARP and it's MAC address for fe:ff:ff:ff:ff:ff 
* Rename veth0 to eth0 
* ifup eth0 (with the old eth0 config) 
* Create bridge xenbr0 and enslave vif0.0 and peth0 to xenbr0 
 
The ifup only works due to the fact that the virtual veth0 somehow 
shadows the real eth0, so it may answer the ARP requests and everything 
else. I actually spent most of today trying to figure out how bridged 
networking is supposed to work. 
 
An alternative might be to set  
(network-script     network-route) 
(vif-script         vif-route) 
in xend-config.sxp and use routing rather than bridging. It's easier to 
understand. 
Unfortunately routing makes migration somewhat harder. 

What happens if you run "ifdown eth0; ifup eth0" after "xend start"?  Any error
messages if you try that?

Whats the network status of the machine?  Please append "brctl show" and "ip
addr ls" and "route -n" output.

"veth0/vif0.0" is the virtual network interface for domain 0, it's kida like a
two-end loopback interface.  Packages dropped into vif0.0 appear on veth0 and
visa versa.  vif0.0 is supposed to be added to xen-br0 like the other vif?.?
interfaces for the xen domains.  Domain0 uses veth0 to talk to the network via
xen-br0.  The physical interface is added to xen-br0 as well to connect all xen
domains (including dom0) to the outside world.

The intention of the interface renaming logic (eth0 => peth0, veth0 => eth0) is
to use the normal distributions way to configure network interfaces, by doing
"ifdown eth0; <create bridge setup here>; ifup eth0", hoping that this gets
corner cases like dhcp correct where the old xen2 approach of copying IP
addresses from one interface to another would simply fail.  This seems not to
work for some reason ...

I think the _real_ solution to that issue would be to have bridge setup support
in the network setup scripts, so xend wouldn't have to do tricks like this in
the first place.

The network setup scripts are much improved in the 10.0 update packages.
Could you please check whether everything works now?

seems to be fixed on SLES10 P4 (tested on i386)