1. Proposed title of this feature request More configuration around interface threshold alerts 3. What is the nature and description of the request? Our customer is currently getting a lot of messages: Host HOSTNAME has network interface which exceeded the defined threshold [95%] (DEV: transmit rate[100%], receive rate [100%]) There is a VM on the customer's network doing more traffic than the hypervisor interface can handle. The customer is aware of it, it is just how this particular VM works. The VM or the traffic is not a problem. However, the customer is getting a lot of these alerts, and would like a way to turn them off. Beyond just disabling alerts per-host or per-interface, we could make the alert interval configurable (vdc_options->event_flood_in_sec). Our customer has some more suggestions: > A feature to allow an administrator to suppress these alerts at a certain > threshold after a certain time elapses would be valuable. For example, if I > could configure on a per-vm basis a setting to allow a VM to operate at 98% > of threshold for 3 minutes before a alert is generated that would be very > useful. I'm not sure how we could do per-VM (surely that would require traffic inspection on the hypervisor and comparing top traffic streams to the VM IP address in vm_dynamic) but we could do that per-interface and per-host. 4. Why does the customer need this? (List the business requirements here) Customer currently has heavy traffic VMs, is unable to avoid the heavy traffic, and is getting heavy logspam every 30 seconds. 5. How would the customer like to achieve this? (List the functional requirements here) Customer would like Red Hat to make interface threshold alerts more configurable. 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Create alert configuration method. Do heavy traffic on a VM so alerts are generated with default alert config. Configure alerts a different way. Do heavy traffic on a VM again, observe alert behaviour. 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? Not that I could see. 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? RHV 4 9. Is the sales team involved in this request and do they have any additional input? No 10. List any affected packages or components. ovirt-engine 11. Would the customer be able to assist in testing this functionality if implemented? We can ask, but this is easy for us to reproduce and test.
HOST_INTERFACE_HIGH_NETWORK_USE already contains anti-flooding configuration, we are logging only 1 message per host and interface per 30 minutes (not seconds as mentioned above) Our anti-flooding mechanism can be setup on source code level per each message. Make it configurable by administrators would need significant effort from infra team, which I don't see as justified. So from infra point of view I suggest to close it as deferred, but forwarding to network team, maybe they see the need to provide some specific solution just for this message. Dan?
Since this bug is about vlan networks on top bond using vdsm-4.20.27.2-1.el7ev, I suspect that the main problem here is bug 1625098. If this persists even after upgrade to rhv-4.2.7, and indeed spams the log every 30 *seconds*, please re-open this bug. *** This bug has been marked as a duplicate of bug 1625098 ***