Hi,
I'm having a hard time getting bonding to work on FC5t3. It looks like the bond0 interface bond0 is renamed to pbond0 by xen [*] and the enslaving does not work anymore then. It works if I log on the terminal and ifenslave the devices to pbond0 instead of bond0 after the boot process has finished.
But I want this to be handled automatically during reboots, so I tried assigning the bonding slaves to pbond0 as a master in the ifcfg-eth{0,1} scripts, but that doesn't work.
What is causing the bond0 rename and should this renaming be considered by initscript? Is this a user error or should I file this against bugzilla? xen or initscripts?
Thanks!
[*] The only reference I found was a Japanese site and google's translation of it.
http://translate.google.com/translate?hl=en&sl=ja&u=http://hoop.euqs...
Axel Thimm (Axel.Thimm@ATrpms.net) said:
I'm having a hard time getting bonding to work on FC5t3.
Not surprising. The way Xen does its bridging breaks bonding fairly badly.
It's possible it could be fixed in the xen scripts, but I don't think it's been looked at.
Bill
On Fri, Feb 24, 2006 at 06:28:20PM -0500, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@ATrpms.net) said:
I'm having a hard time getting bonding to work on FC5t3.
Not surprising. The way Xen does its bridging breaks bonding fairly badly.
It's possible it could be fixed in the xen scripts, but I don't think it's been looked at.
are the xen scripts called by initscripts? E.g. will this logic be encapsulated in such a way that an ifdown/ifup on bond0 outside the boot sequence would do the right thing w/o initscripts knowing anything more about xen, or would initscripts still require some special xen handling?
I haven't looked to deeply into xen, so I may be missing the obvious here.
On Fri, Feb 24, 2006 at 06:28:20PM -0500, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@ATrpms.net) said:
I'm having a hard time getting bonding to work on FC5t3.
Not surprising. The way Xen does its bridging breaks bonding fairly badly.
It's possible it could be fixed in the xen scripts, but I don't think it's been looked at.
I now jumped into the xen networking concepts. These make sense, but there are two issues:
a) bonding should be performed onto the "physical" bonding interface, which xen renames to pbond0. Still the initscripts only work with MASTER=pbond0 if called *after* completion of the boot process.
b) even if a) is fixed and requires MASTER=pbond0 setting, the switching from a xen kernel to a non-xen kernel the configuration in the initscripts would be bogus (pointing to a nonexisting pbond0), and the bonding device would be w/o slaves.
I don't understand why a) happens, seems to be dependent on the order of the steps performed. Maybe the bonding/enslaving (at boot time) happens before xen renames the bond0 device and later on the enslaving is wrong. Reruning the ifup scripts sees the renamed devices and performs properly. That's a theory at least.
I'm not sure how to solve b). Ideally one would like to not have xen specific actions in initscripts, but otherwise one risks cutting of the system of the net completely when upgrading kernels and booting into the wron one. Probably not something one wants when setting up bonding to ensure network availability. ;)
Should I file a bugzilla? xen or initscripts?
Axel Thimm (Axel.Thimm@ATrpms.net) said:
I don't understand why a) happens, seems to be dependent on the order of the steps performed. Maybe the bonding/enslaving (at boot time) happens before xen renames the bond0 device and later on the enslaving is wrong.
Correct.
I'm not sure how to solve b). Ideally one would like to not have xen specific actions in initscripts, but otherwise one risks cutting of the system of the net completely when upgrading kernels and booting into the wron one. Probably not something one wants when setting up bonding to ensure network availability. ;)
Should I file a bugzilla? xen or initscripts?
Ideally, xen shouldn't be mucking with networking that much. It does it because of some supposed race.
Bill
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list