|
Bugzilla – Full Text Bug Listing |
| Summary: | XEN ifcfg interferes with regular ifcfg | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Martin Vidner <mvidner> |
| Component: | YaST2 | Assignee: | 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
Created attachment 49400 [details]
y2logs.tgz
*grumble*, suse bugzilla used to automatically Accept reports from self, it was probably lost when migrating. Is this still broken in SUSE 10.1? I think so. 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. *** Bug 171533 has been marked as a duplicate of this bug. *** (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? 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. 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. 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) |