Bug 189473

Summary: bonding: xenbr after boot broken, after xend restart networking gone altogether
Product: [Fedora] Fedora Reporter: Axel Thimm <axel.thimm>
Component: xenAssignee: Xen Maintainance List <xen-maint>
Status: CLOSED WONTFIX QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: medium    
Version: 12CC: bstein, herbert, masanari_iida, mbrodeur, poelstra, tjb, triage, virt-maint
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-05 02:18:03 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 213559    
Bug Blocks:    
Attachments:
Description Flags
xen/network status right after booting
none
xen/network status after xend restart
none
Xen bonding network problem situation none

Description Axel Thimm 2006-04-20 08:02:51 EDT
Description of problem:
I set up bonding between two interfaces eth0 and eth1 to bond0. This works fine
under non-xen operation.

Booting into a xen kernel the xenbr misses the bond0 interface at first and
doesn't create/rename/attach any interfaces, the networking is as w/o xen, only
the broken xenbr is also there.

Calling xend restart seems to catch the bond0 device this time (renames it to
pbond0 and creates a new bond0), but removes the ethX enslaving and downs these
interfaces killing all networking.


Version-Release number of selected component (if applicable):
xen-3.0.1-4

How reproducible:
always

Steps to Reproduce:
1.classically bond eth0 and eth1 to bond0
2.boot into kernel-xen0 (-> no xen bridging, but otherwise still networking)
3.service xend restart (-> network is down, no enslaved interfaces anymore)
  
Actual results:
Either malfunctional xenbr, or no networking at all.

Expected results:
xenbr should attach pbond0 (already in the first invocation by the boot
sequence) and keep the enslaving inferfaces attached and running.

Additional info:
There are two log files attached from running

ifconfig
route -n
/etc/xen/scripts/network-bridge status

right after the boot and then after service xend restart. The differences show
that xend restart removes eth0 and eth1 (bad), properly renames bond0 to pbond0
(ok), creates bond0 and vif0.0 and attaches these to xenbr.

Summing up the issues are:
a) why doesn't the booting sequence already try to handle bond0, but requres a
   xend restart?
b) why are the enslaving ethX intefaces lost after a xend restart?

Thanks!
Comment 1 Axel Thimm 2006-04-20 08:02:51 EDT
Created attachment 128032 [details]
xen/network status right after booting
Comment 2 Axel Thimm 2006-04-20 08:04:35 EDT
Created attachment 128033 [details]
xen/network status after xend restart
Comment 3 Axel Thimm 2007-03-04 03:48:46 EST
This is still an issue on FC6 and is architecture independent.
Comment 4 Red Hat Bugzilla 2007-07-24 19:54:22 EDT
change QA contact
Comment 5 Thomas J. Baker 2007-11-20 09:33:32 EST
I believe I'm seeing similar results on Fedora 8. Trying to use bonding with xen
resulted in extremely flaky networking. Strange for me though is that I had it
working fine in FC6.
Comment 6 Axel Thimm 2007-11-20 11:15:33 EST
It is true for any xen system as it is independent of xen, really. It also
affects RHE in the same way. I'll move the version up to devel, so the bug
doesn't get lost with FC6 going EOL.

The "bug" or missing configuration parameters are in the interaction of bonding
and bridging causing echo loops and thus broken forwarding databases - had the
bridging code some possibility of nailing down a MAC to a bridge port or
otherwise detect looped packages or echo'ed MAC addresses this would not happen.
This also affects other virtualization software as well.

I raised this a couple of months ago on both bridge and bonding list with quite
a deafening silent feedback. So ATM you can only use bonding if you have smart
switches on the other side that will not loopback your outgoing packages. Most
such switches will then not let you PXE boot anymore if you defined trunked
segments, so you need to choose what is more important to you :/
Comment 7 Herbert Straub 2007-11-23 12:54:14 EST
Created attachment 267721 [details]
Xen bonding network problem situation
Comment 8 Herbert Straub 2007-11-23 12:54:59 EST
I have also a problem with bonding and xen on RHEL 5.1. I configured bonding and
it works. If I start xend, then the network connection becomes unstable (hangin,
working, hanging...). I can see the raising error count. I attached the
configuration (attachment in comment #7).
Comment 9 Bug Zapper 2008-04-03 13:12:16 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 10 Axel Thimm 2008-04-03 18:05:41 EDT
Bridging and bonding are still not working properly.
Comment 11 Bug Zapper 2008-05-13 22:08:32 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 masanari iida 2008-11-06 05:32:18 EST
Has this already fixed on RHEL5.2 or upcoming 5.3 ?
If 5.3 still has this problem, plese put the info 
into release note, "Known Issue" section.
Comment 13 John Poelstra 2008-11-06 17:20:02 EST
(In reply to comment #12)
> Has this already fixed on RHEL5.2 or upcoming 5.3 ?
> If 5.3 still has this problem, plese put the info 
> into release note, "Known Issue" section.

Note this bug is open for the "Fedora Product".  We do not track RHEL issues here.  Please raise this question through your regular support vehicle, TAM, or Partner Manager.

Thank you,
John
Comment 14 Axel Thimm 2008-11-08 02:20:45 EST
(In reply to comment #13)
> Note this bug is open for the "Fedora Product".  We do not track RHEL issues
> here.  Please raise this question through your regular support vehicle, TAM, or
> Partner Manager.

Actually I originally encountered this on RHEL, but I only have support-free developer licenses. Maybe here even is a bug report on RHEL by me with a similar answer as above ("elevate ticket status through XYZ").

At least I had a couple of RHEL bugs I had to degrade to Fedora bugs as I can't raise their importance.

FWIW the bonding/bridging issue is still out there for any Linux distribution, be it Fedora, RHEL or LFS.
Comment 15 masanari iida 2008-12-10 00:32:13 EST
(In reply to comment #14)

If you have only one bonding (eth0+eth1), 
I think following setting create pbond0 for you.

/etc/xen/xend-config.sxp
 
(network-script 'network-bridge netdev=bond0')

So, I think this is a configuration issue because of
lack of good document for how to configure Xen networking.

Currently, my problem is vlan setting in Xen environment.
(Sigh.)
Comment 16 Bug Zapper 2009-06-09 18:08:52 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Bug Zapper 2009-07-14 13:25:42 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 18 Bug Zapper 2009-11-16 02:51:10 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bug Zapper 2010-11-04 08:16:11 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 20 Bug Zapper 2010-12-05 02:18:03 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.