Hide Forgot
Created attachment 1222759 [details] Insight rule lacp-compliant screen shot When Insights analyzes both RHV 3.6 and 4.0, using bond mode 4 on the hypervisor host, an error is reported stating that the xmit_hash_policy is not configured. RHV defaults to the xmit_hash_policy=layer2. The layer2 policy is a LACP-compliant policy. The message should be changed to reflect that. I'm also opening a ticket in RHV to change the default xmit_hash_policy to layer2+3 since that is the RHEL recommended bond 4 xmit_hash_policy.
In order to change rhv's default (as requested in bug 1397490) I would like to better understand the reasons for the statement "Red Hat recommends you use layer2+3 as the hash algorithm"
Originally this rule was based off of https://access.redhat.com/solutions/666853. Jamie Bainbridge replied to my questions with a statement that is similar to what he said in bug 1397490. "I spoke to Xiaoyu about this, he is already going to change the rule so we're ALSO looking at each bond slave per Aggregator, and if one slave on the active Aggregator had done the majority of traffic, this rule triggers. An example of unbalanced RX/TX is given in the Issue of the KCS. Looking at telemetry/rules/plugins/bonding/bonding_lacp.py it doesn't appear he's had the chance to update the rule yet. We discussed this via email, I am not sure if there is a Jira open for it. As I commented on Bug 1397490, there is no "recommended" value anyway and the ideal value will differ per environment. There are even some environments where this will trigger and it cannot be resolved because the workload is a single stream (eg: NFS Client to one NFS Server, ISCSI initiator to one ISCSI target, etc). Virtualization is not a factor." Xiaoyu will this still hit on RHV4 after the changes to the plugin?