RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 647155 - [vdsm] bond is configured by default when service starts with no actual reason
Summary: [vdsm] bond is configured by default when service starts with no actual reason
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm
Version: 6.1
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Dan Kenigsberg
QA Contact: Yaniv Kaul
URL:
Whiteboard:
Depends On: 649239 918666 951018
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-27 12:29 UTC by Haim
Modified: 2013-07-04 02:11 UTC (History)
7 users (show)

Fixed In Version: vdsm-4.9-52.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-19 15:25:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Haim 2010-10-27 12:29:52 UTC 
Description of problem:

vdsm configures bond 0-4 each time service starts (see log from dmesg). 
bond configuration should be done on the fly if such requirement comes from user . 
from short conversation I had with backend team, there is no longer such requirement from their side, however, this should be tested before such commit being performed, as we don't want to cause any regression. 

Oct 25 12:04:23 magenta-vdsd kernel: bonding: bond0 is being created...
Oct 25 12:04:23 magenta-vdsd kernel: bonding: cannot add bond bond0; already exists
Oct 25 12:04:23 magenta-vdsd kernel: bonding: Bond creation failed.
Oct 25 12:04:23 magenta-vdsd kernel: bonding: bond1 is being created...
Oct 25 12:04:23 magenta-vdsd kernel: bonding: cannot add bond bond1; already exists
Oct 25 12:04:23 magenta-vdsd kernel: bonding: Bond creation failed.
Oct 25 12:04:23 magenta-vdsd kernel: bonding: bond2 is being created...
Oct 25 12:04:23 magenta-vdsd kernel: bonding: cannot add bond bond2; already exists
Oct 25 12:04:23 magenta-vdsd kernel: bonding: Bond creation failed.
Oct 25 12:04:23 magenta-vdsd kernel: bonding: bond3 is being created...
Oct 25 12:04:23 magenta-vdsd kernel: bonding: cannot add bond bond3; already exists
Oct 25 12:04:23 magenta-vdsd kernel: bonding: Bond creation failed.
Oct 25 12:04:23 magenta-vdsd kernel: bonding: bond4 is being created...
Oct 25 12:04:23 magenta-vdsd kernel: bonding: cannot add bond bond4; already exists
Oct 25 12:04:23 magenta-vdsd kernel: bonding: Bond creation failed.
Oct 25 12:31:17 magenta-vdsd kernel: bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details.


[root@gold-vdsd ~]# ifconfig -a  |more
bond0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond1     Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond2     Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond3     Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond4     Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Comment 2 Barak 2010-11-28 17:12:20 UTC 
Since this is an API change between VDSM & RHEVM (RHEVM expects the first 5 bonds to be reported always) then we will handle continue configuring the first 5 bonds during VDSM startup, but if a request for the 6th bond will arrive we will create it dynamically. 
Deletion will not be handled at this satge - meaning when the 6th bond will be deleted (from RHEVM) the vdsm will continue report it's status.
Comment 3 Avi Tal 2010-12-27 13:12:57 UTC 
vdsm-4.9-33.el6.x86_64 Fixed

I've been running addNetwork/del/edit from vdsClient.
as written in comment 2, it does create the extra bond and attach the nic's correctly but never remove the new created bonds
Note You need to log in before you can comment on or make changes to this bug.