Previously, using the Red Hat Enterprise Virtualization API to change options on a NIC (network interface card) sub-interface erased and reverted to default settings any pre-configured bonding options. Now, bonding options are preserved.
Description of problem:
Version-Release number of selected component (if applicable):
3.2
Using the RHEV 3.2 python SDK/API(assuming the later) to change the IP addressing on a hypervisor bonding NIC sub-interface causes the bonding NIC and slave NIC configs to be re-written/re-configured(understandably so, especially if we attach a new sub-interface with a larger MTU). If the desired bonding options for the bonding NIC aren't passed with the sub-interface IP settings, the bonding NIC options will revert to the default settings. This shouldn't be necessary and it requires that one detect that they're working with a sub-interface and capture the existing bonding options to submit with the IP change.
This is the sub-interface IP address changing sequence that's being used:
host = API().hosts.get(name=hostName)
nic = host.nics.get(name=nicName)
nic.set_boot_protocol("static")
nic.set_ip(params.IP(address=ip, netmask=mask, gateway=gw))
nic = nic.update()
The current behavior requires us to also do something like this prior to the update():
rem = re.match(r"^(bond\d+)\.\d+$", nic.name)
parentNicName = rem.group(1)
parentNic = host.nics.get(name=parentNicName)
nic.set_bonding(parentNic.bonding)
Additional info:
This issue is expected to be on 3.3 as well. We will try to test once we have our 3.3 environment set up.
In order to clarify the described scenario, which is verified to exist on 3.3 as well:
When a vlan 10 network is attached to bond0, it creates a new device named bond0.10.
When updating the bond0.10 device (i.e. boot protocol), the bonding options is being removed from from the bond0, although it wasn't designed to be changed.
The engine should not override in this case the bonding options which weren't supplied by the user in this case and maintain the previous bonding options, as currently configured on the engine db.
While this bug should be fixed for 3.0 api, is there any reason why not to use setup networks api ? Is it a 3.0 cluster ?
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHSA-2014-0506.html
Description of problem: Version-Release number of selected component (if applicable): 3.2 Using the RHEV 3.2 python SDK/API(assuming the later) to change the IP addressing on a hypervisor bonding NIC sub-interface causes the bonding NIC and slave NIC configs to be re-written/re-configured(understandably so, especially if we attach a new sub-interface with a larger MTU). If the desired bonding options for the bonding NIC aren't passed with the sub-interface IP settings, the bonding NIC options will revert to the default settings. This shouldn't be necessary and it requires that one detect that they're working with a sub-interface and capture the existing bonding options to submit with the IP change. This is the sub-interface IP address changing sequence that's being used: host = API().hosts.get(name=hostName) nic = host.nics.get(name=nicName) nic.set_boot_protocol("static") nic.set_ip(params.IP(address=ip, netmask=mask, gateway=gw)) nic = nic.update() The current behavior requires us to also do something like this prior to the update(): rem = re.match(r"^(bond\d+)\.\d+$", nic.name) parentNicName = rem.group(1) parentNic = host.nics.get(name=parentNicName) nic.set_bonding(parentNic.bonding) Additional info: This issue is expected to be on 3.3 as well. We will try to test once we have our 3.3 environment set up.