Created attachment 895424 [details] vdsm logs Description of problem: Only for network attached to BOND When updating network with new IP address (for the network that already has IP) the new IP is not updated on the host and if we update the IP address again the previos IP is updated on the host. For example: Network "net1" with ip 1.1.1.1 > in setupNetworks edit the network and update the IP to 1.1.1.2 Though on GUI the IP address is 1.1.1.2, on the host the IP for "net1" is still 1.1.1.1 and getVdsCaps report 1.1.1.1 In setupNetworks edit the network and update the IP to 1.1.1.3 Though on GUI the IP address is 1.1.1.3, on the host the IP is 1.1.1.2 and getVdsCaps report 1.1.1.2 It seems that ifup called before the ifcfg file is updated with the new IP. Version-Release number of selected component (if applicable): vdsm-4.14.7-2.el6ev.x86_64 rhevm-3.4.0-0.20.el6ev.noarch How reproducible: 100% Steps to Reproduce: 1.Create network "net1", 2.In seupNetworks create BOND and attach the network to the BOND and add IP 1.1.1.1 3.In setupNetworks edit "net1" IP to 1.1.1.2 > check IP on the host (ifconfig bond(X)) 4.In setupNetworks edit "net1" IP to 1.1.1.3 > check IP on the host (ifconfig bond(X)) Actual results: IP is not updated on the host Expected results: IP should be updated on the host Additional info:
Created attachment 895438 [details] Proper vdsm logs
Only happens for non-vm network over BOND.
From the logs I can see: Thread-16::DEBUG::2014-05-14 13:26:39,826::BindingXMLRPC::1067::vds::(wrapper) client [10.35.163.63]::call setupNetworks with ({'mode0_non_vm': {'bonding': 'bond0', 'ipaddr': '1.1.1.1', 'netmask': '255.255.255.0', 'bridged': 'false'}, 'mode_4': {'remove': 'true'}}, {}, {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {} flowID [1ff1e6a1] . . . Thread-16::DEBUG::2014-05-14 13:26:48,245::BindingXMLRPC::1074::vds::(wrapper) return setupNetworks with {'status': {'message': 'Done', 'code': 0}} And the next getCapabilities includes: 'bond0': {'netmask': '255.255.255.0', 'addr': '1.1.1.1', 'slaves': ['eth2', 'eth3'], 'hwaddr': '00:10:18:24:4a:fc', 'cfg': {'DEFROUTE': 'no', 'IPADDR': '1.1.1.1', 'NM_CONTROLLED': 'no', 'NETMASK': '255.255.255.0', 'BOOTPROTO': 'none', 'BONDING_OPTS': 'mode=4 miimon=100', 'DEVICE': 'bond0', 'ONBOOT': 'yes'}, 'ipv6addrs': ['fe80::210:18ff:fe24:4afc/64'], 'mtu': '1500'} After that: Thread-16::DEBUG::2014-05-14 13:26:58,858::BindingXMLRPC::1067::vds::(wrapper) client [10.35.163.63]::call setupNetworks with ({'mode0_non_vm': {'bonding': 'bond0', 'ipaddr': '1.1.1.2', 'netmask': '255.255.255.0', 'bridged': 'false'}}, {}, {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {} flowID [7ad27bdf] . . . Thread-16::DEBUG::2014-05-14 13:27:09,008::BindingXMLRPC::1074::vds::(wrapper) return setupNetworks with {'status': {'message': 'Done', 'code': 0}} And the next getCapabilities includes: Thread-16::DEBUG::2014-05-14 13:27:09,008::BindingXMLRPC::1074::vds::(wrapper) return setupNetworks with {'status': {'message': 'Done', 'code': 0}} 'bond0': {'netmask': '255.255.255.0', 'addr': '1.1.1.2', 'slaves': ['eth2', 'eth3'], 'hwaddr': '00:10:18:24:4a:fc', 'cfg': {'DEFROUTE': 'no', 'IPADDR': '1.1.1.2', 'NM_CONTROLLED': 'no', 'NETMASK': '255.255.255.0', 'BOOTPROTO': 'none', 'BONDING_OPTS': 'mode=4 miimon=100', 'DEVICE': 'bond0', 'ONBOOT': 'yes'}, 'ipv6addrs': ['fe80::210:18ff:fe24:4afc/64'], 'mtu': '1500'} After that: Thread-16::DEBUG::2014-05-14 13:27:21,689::BindingXMLRPC::1067::vds::(wrapper) client [10.35.163.63]::call setupNetworks with ({'mode0_non_vm': {'bonding': 'bond0', 'ipaddr': '1.1.1.3', 'netmask': '255.255.255.0', 'bridged': 'false'}}, {}, {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {} flowID [6ad1c1da] . . . Thread-16::DEBUG::2014-05-14 13:27:32,053::BindingXMLRPC::1074::vds::(wrapper) return setupNetworks with {'status': {'message': 'Done', 'code': 0}} And the next getCapabilities includes: 'bond0': {'netmask': '255.255.255.0', 'addr': '1.1.1.3', 'slaves': ['eth2', 'eth3'], 'hwaddr': '00:10:18:24:4a:fc', 'cfg': {'DEFROUTE': 'no', 'IPADDR': '1.1.1.3', 'NM_CONTROLLED': 'no', 'NETMASK': '255.255.255.0', 'BOOTPROTO': 'none', 'BONDING_OPTS': 'mode=4 miimon=100', 'DEVICE': 'bond0', 'ONBOOT': 'yes'}, 'ipv6addrs': ['fe80::210:18ff:fe24:4afc/64'], 'mtu': '1500'} I fail to see the issue with the provided logs.
Went to manually test on a host. In [19]: c.setupNetworks({'mode0_non_vm': {'bonding': 'bond0', 'ipaddr': '1.1.1.1', 'netmask': '255.255.255.0', 'bridged': 'false'}}, {'bond0': {'nics': ['eth2', 'eth3']}}, {'connectivityCheck': False}) Out[19]: {'status': {'code': 0, 'message': 'Done'}} In [24]: list(addr for addr in netinfo.iter_addrs() if addr['label'] == 'bond0') Out[24]: [{'address': '1.1.1.1/24', 'family': 'inet', 'flags': 128, 'index': 10, 'label': 'bond0', 'prefixlen': 24, 'scope': 'universe'}, {'address': 'fe80::201:a4ff:feac:8701/64', 'family': 'inet6', 'flags': 128, 'index': 10, 'label': 'bond0', 'prefixlen': 64, 'scope': 'link'}] In [25]: c.setupNetworks({'mode0_non_vm': {'bonding': 'bond0', 'ipaddr': '1.1.1.2', 'netmask': '255.255.255.0', 'bridged': 'false'}}, {},{'connectivityCheck': False}) Out[25]: {'status': {'code': 0, 'message': 'Done'}} In [26]: list(addr for addr in netinfo.iter_addrs() if addr['label'] == 'bond0') Out[26]: [{'address': '1.1.1.1/24', 'family': 'inet', 'flags': 128, 'index': 10, 'label': 'bond0', 'prefixlen': 24, 'scope': 'universe'}, {'address': '1.1.1.2/24', 'family': 'inet', 'flags': 129, 'index': 10, 'label': 'bond0', 'prefixlen': 24, 'scope': 'universe'}, {'address': 'fe80::201:a4ff:feac:8701/64', 'family': 'inet6', 'flags': 128, 'index': 10, 'label': 'bond0', 'prefixlen': 64, 'scope': 'link'}] In [27]: c.setupNetworks({'mode0_non_vm': {'bonding': 'bond0', 'ipaddr': '1.1.1.3', 'netmask': '255.255.255.0', 'bridged': 'false'}}, {},{'connectivityCheck': False}) Out[27]: {'status': {'code': 0, 'message': 'Done'}} In [28]: list(addr for addr in netinfo.iter_addrs() if addr['label'] == 'bond0') Out[28]: [{'address': '1.1.1.2/24', 'family': 'inet', 'flags': 128, 'index': 10, 'label': 'bond0', 'prefixlen': 24, 'scope': 'universe'}, {'address': '1.1.1.3/24', 'family': 'inet', 'flags': 129, 'index': 10, 'label': 'bond0', 'prefixlen': 24, 'scope': 'universe'}, {'address': 'fe80::201:a4ff:feac:8701/64', 'family': 'inet6', 'flags': 128, 'index': 10, 'label': 'bond0', 'prefixlen': 64, 'scope': 'link'}] We can see that the abnormal behavior is that after changing the address to 1.1.1.2 instead of changing it it has merely been added as a secondary ipv4 address and that after changing it to 1.1.1.3, 1.1.1.2 became the primary and the new address became secondary. The ipaddresses are still being configured and functional, and as shown in the logs in the previous comment, the ifcfg files ('cfg' field) of the bond0 is correct at each interval. I've got to check if we are doing some wrong flow or if the bug lies with initscripts.
The bug is caused by the bond removal (before the addition of the modified network) not clearing the ifcfg file IP configuration fields.
Caused by http://gerrit.ovirt.org/18911
... and with us since 3.3, so not a recent regression.
ovirt-engine-3.5.0-0.0.master.20140715172116.git4687dc1.el6.noarch vdsm-4.16.0-27.git00146ed.el6.x86_64
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. https://rhn.redhat.com/errata/RHBA-2015-0159.html