Description of problem: Currently the user suddenly hits a wall once the MAC Address Pool runs out of addresses, and vNICs fail to add. ~~~ Cannot add Interface. Not enough MAC addresses left in MAC Address Pool. ~~~ It is not a good experience, because the is no previous warning, the problem appears suddenly when the pool is exhausted (too late). Please implement some Warning Event, similar to already existing CPU/Network/Memory thresholds that warns the user via event in audit log that a MAC Pool available addresses left are below a certain threshold. For example: ~~~ MAC Pool xxx utilization has exceeded the defined threshold [95%] ~~~ Or the other way around: ~~~ MAC Pool xxx available addresses is below the defined threshold [5%] ~~~ The Threshold could be adjustable by engine-config, like the engine already has for other ones: # engine-config -a | grep -i threshold ... LogPhysicalMemoryThresholdInMB: 1024 version: general LogMaxPhysicalMemoryUsedThresholdInPercentage: 95 version: general LogMaxCpuUsedThresholdInPercentage: 95 version: general LogMaxNetworkUsedThresholdInPercentage: 95 version: general ... The check could be done in a timed interval, or on every allocation of MAC from pool (rate limited). Note the engine already has something similar when it is restarted, although this doesn't seem to check addresses actually available, just free MACs on the pool itself: 2020-09-15 09:43:43,411+10 INFO [org.ovirt.engine.core.bll.network.macpool.MacPoolPerCluster] (ServerService Thread Pool -- 49) [] Mac pool 58ca604b-017d-0374-0220-00000000014e has 65535 available free macs We should have something similar that runs regularly and triggers a WARN at a configurable threshold.
Germano, would be also the warning on a small absolute number of free MAC addresses helpful? (I guess the implementation would be to check for a number free MAC address of a mac pool if they are unused globally, which would come at the cost of db usage. To keep the count of db queries low, we should warn only late. And to avoid a unreadable threshold like 99.5% of the MAC pool, maybe something like 100 free MAC addresses would be more intuitive for the user.)
(In reply to Dominik Holler from comment #1) > Germano, would be also the warning on a small absolute number of free MAC > addresses helpful? > (I guess the implementation would be to check for a number free MAC address > of a mac pool if they are unused globally, which would come at the cost of > db usage. > To keep the count of db queries low, we should warn only late. And to avoid > a unreadable threshold like 99.5% of the MAC pool, maybe something like 100 > free MAC addresses would be more intuitive for the user.) Makes sense to me. The only thing is if the user has small MAC pools it could produce many warnings with a hard number. So if the '100' is configurable I think this is a good solution.
Verified on - rhvm-4.5.0-0.237.el8ev.noarch
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 (Moderate: RHV Manager (ovirt-engine) [ovirt-4.5.0] security update), 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://access.redhat.com/errata/RHSA-2022:4711