Bug 116125

Summary: XEN ifcfg interferes with regular ifcfg
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Martin Vidner <mvidner>
Component: YaST2Assignee: Martin Vidner <mvidner>
Status: RESOLVED FIXED QA Contact: Klaus Kämpf <kkaempf>
Severity: Normal    
Priority: P5 - None CC: jfriedl, lslezak, max
Version: RC 1   
Target Milestone: ---   
Hardware: Other   
OS: All   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: y2logs.tgz

Description Martin Vidner 2005-09-09 13:25:52 UTC
Jakub had a problem with a nonfunctioning network interface. It turned out 
that the hwcfg-bus-pci-0000:00:0a.0 did not contain the name of the driver 
module.  
  
Apparently while using XEN he configured the interface again which was then  
detected with a different MAC, fe:ff:ff:ff:ff:ff[*]. Then he deleted it. That  
deleted also the hwcfg even though it was still needed by the original ifcfg  
with the real MAC.  
  
[*] See /usr/share/doc/packages/xen/README.SuSE
Comment 1 Martin Vidner 2005-09-09 13:27:38 UTC
Created attachment 49400 [details]
y2logs.tgz
Comment 2 Martin Vidner 2005-09-12 22:41:18 UTC
*grumble*, suse bugzilla used to automatically Accept reports from self, it was 
probably lost when migrating.
Comment 3 Lynn Bendixsen 2006-03-17 16:14:53 UTC
Is this still broken in SUSE 10.1?  
Comment 4 Martin Vidner 2006-04-05 17:22:36 UTC
I think so.
Comment 5 Kirk Allan 2006-04-27 15:28:56 UTC
In Xen when networking is setup up to use bridging via the network-bridge script, it seems that users can get themselves into trouble by modifying the network interfaces after the interfaces have been added to the bridge.

The README.SuSE file gives an explanation of what goes on when bridging.  Here is an excerpt. “When using bridging, the eth0 in domain 0 device will be renamed to peth0 and its MAC address will be set to fe:ff:ff:ff:ff:ff and ARP will be disabled. veth0 will take over the old MAC address, be renamed to eth0, and be enabled (ifup'ed).  vif0.0 and peth0 are then enslaved to xenbr0.  veth0 is connected to vif0.0 behind the scenes.”

Because of all the manipulation of eth0, configuring eth0 after bridging has taken place doesn't do what is expected.  As an enhancement, would it be possible to have yast disable configuration of network interfaces that have been setup and are running in bridged mode with Xen?  A message could also be displayed indicating that the network interfaces can't be configured while running behind the bridge.  If the user stopped the bridge and got networking set back to normal, then the user could go and configure the interface and then start the bridge back up.  This way a lot of configuration mishaps could be avoided.
Comment 6 Kirk Allan 2006-05-02 15:52:07 UTC
*** Bug 171533 has been marked as a duplicate of this bug. ***
Comment 7 Reinhard Max 2006-05-02 16:10:37 UTC
(In reply to comment #5)
> As an enhancement, would it be
> possible to have yast disable configuration of network interfaces that have
> been setup and are running in bridged mode with Xen?

I think The Right Thing to do here would be to integrate the bridge setup of Xen (or even generic support for bridge devices) with the regular networking scripts so that a "rcnetwork restart" shuts it down and brings it back up in the right order.

Why not just having /etc/sysconfig/network/ifcfg-* scripts also for the Xen related network devices instead of mucking with the network setup behind the back of YaST and the sysconfig mechanims?
Comment 8 Reinhard Max 2006-05-03 17:32:27 UTC
Another problem I just stumbled over is, that once the bridging has been set up during the start of xend, syslog is flooded by messages that say:

   "peth0: received packet with  own address as source address"


Kirk, what's the purpose of that vethX and pethX renaming thing?

Couln't the physical ethernet device just be enslaved to the bridging device, and the IP and MAC addresses be transferred to it? If that'd work, the configuration of the eth and bridge device could be part of the regular network configuration under /etc/sysconfig/network and thus less interfer with the regular networking scripts.
Comment 9 Kirk Allan 2006-05-03 17:54:03 UTC
Bug #161888 has been entered for the "peth0: received packet with  own address as source address" problem.  Could you enter any additional information you have on this issue on that bug?

XenSouce introduced the vethX and pethX in the network-bridge script.  I don't understand the full implications of it.

I entered information on how to stop and start the bridge in the xen README.SuSE file as requested.
Comment 10 Lynn Bendixsen 2006-07-31 16:05:08 UTC
I don't think that the original reason this bug was opened still exists.  Also we are not fixing problems anymore for 10.0 (currently we are working towards 10.2). I propose that we close this bug.
Martin or Kirk,
Please reopen this bug with the summary and the product changed if you disagree with my first statement AND/OR please open a new bug with the Network setup issues clearly explained so that we can get this stuff working nicely from a Yast perspective (as desired, and if the current workaround is not acceptable for the long term)