Hide Forgot
Don't know if this is related with https://bugzilla.redhat.com/show_bug.cgi?id=1391130 In the Web interface (Setup Host Networks) I can see information for the custom bonding but it's wrong: /var/lib/vdsm/persistence/netconf/bonds/bond0: "switch": "legacy", "options": "mode=1 arp_interval=1000 arp_ip_target=10.1.2.1,10.1.3.1 primary=p5p 1" /etc/sysconfig/network-scripts/ifcfg-bond0: BONDING_OPTS='mode=1 arp_interval=1000 arp_ip_target=10.1.2.1,10.1.3.1 primary=p5p1' In the gui it shows: " arp_interval=1000 mode=1 arp_ip_target=10.1.3.1 primary=p5p1" There are two errors: 1) One space in front 2) 10.1.2.1 is missing from arp_ip_target
Could you add a screenshot?
Created attachment 1240253 [details] screenshot-1
Created attachment 1240254 [details] screenshot-2
bug 1391130 referred only to visual alignment. here we have a problem with content, which was not fixed. Could you help a bit more by providing `vdsClient -s getVdsCaps` from the host, to make sure the problem is only on Engine?
bondings = {'bond0': {'active_slave': 'p5p1', 'addr': '10.1.2.31', 'cfg': {'BONDING_OPTS': 'mode=1 arp_interval=1000 arp_ip_target=10.1.2.1,10.1.3.1 primary=p5p1', 'BOOTPROTO': 'none', 'DEFROUTE': 'yes', 'DEVICE': 'bond0', 'DNS1': 'xxx, 'DNS2': 'xxx', 'GATEWAY': '10.1.2.1', 'IPADDR': '10.1.2.31', 'IPV6INIT': 'no', 'MTU': '1500', 'NETMASK': '255.255.255.0', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes'}, The vds seems fine to me.
A question: Where does the engine get these details? Are they stored in the database or does it query the client?
Engine does both: it stores BONDING_OPTS in its DB, and it calls Vdsm's getVdsCaps. It seems that Engine's front end bulks on an option with a comma in its value. However, which Vdsm version do you use? the output of getVdsCaps in comment 5 seems partial. It should have had an 'opts': {'mode': '0'....} line.
yes i missed that line: 'opts': {'arp_interval': '1000', 'arp_ip_target': '10.1.3.1', 'mode': '1', 'primary': 'p5p1'}, It shows only one IP there. vdsm-4.18.21-1
So Engine is not to blame. What's in ifcfg-bond0 and /sys/class/net/bond0/bonding/arp_ip_target ?
ifcfg-bond0: BONDING_OPTS='mode=1 arp_interval=1000 arp_ip_target=10.1.2.1,10.1.3.1 primary=p5p1' /sys/class/net/bond0/bonding/arp_ip_target: 10.1.2.1 10.1.3.1 /proc/net/bonding/bond0: Bonding Mode: fault-tolerance (active-backup) Primary Slave: p5p1 (primary_reselect always) ARP Polling Interval (ms): 1000 ARP IP target/s (n.n.n.n form): 10.1.2.1, 10.1.3.1 All there are correct
vdsm should report space-separated arp_ip_target option properly. The kernel converted "10.1.2.1,10.1.3.1" to "10.1.2.1 10.1.3.1". We (Engine+Vdsm) should decide on one separator (either space of comma) and use it for both input and output.
Also keep in mind (comment 1) that the UI also adds a wrong space in front of the options
Kapetanakis, could you tell if setting a space-separated list works? "mode=1 arp_interval=1000 arp_ip_target='10.1.2.1 10.1.3.1' primary=p5p1" note that you'd still see it reported badly in GUI, but I'd like to know if anything else (including REST and /sys/class/net/bond0/bonding/arp_ip_target) works fine.
The UI does not let me to set it up like this.
Only one issue of two has fixed on this build. Engine and vdsm report now multiple IPs for arp_ip_target. The cosmetic gap wasn't fix. Setting to verified and will report new bug for the cosmetic UI gap. Verified on - 4.1.1-0.1.el7 and vdsm-4.19.5-1.el7ev.x86_64
About the second bug, it's not just cosmetic. If you leave the space in front then you cannot apply/ok as the UI get's it as an error. You have to manually (guess and) delete the space to OK. Is there a bug id for this submitted?
This behavior occurs, if the option "miimon" is missing. During formatting the options string the "mode" and "miimon" options are placed together at first place in the string, and the other options are separated by a space. If one of the "mode" and "miimon" options is missing, nothing is placed before the space.
This issue if fixed by https://gerrit.ovirt.org/#/c/70923/ in master. If this issue is very urgent, please file a new bug.
(In reply to Dominik Holler from comment #18) > This issue if fixed by https://gerrit.ovirt.org/#/c/70923/ in master. If > this issue is very urgent, please file a new bug. See BZ 1429810