Description of problem: The memory usage number in VDS_HIGH_MEM_USE warning should be the usage of normal memory, not the total usage of normal memory and hugepages memory. Version-Release number of selected component (if applicable): ovirt-engine-4.5.1.2-0.11.el8ev.noarch How reproducible: 100% Steps to Reproduce: 1. Set the cluster memory threshold to 50% 2. On a host(not running any VM) with 62G total memory, reserve 40G (64.5%) with HugePages # egrep '^HugePages_|^Mem' /proc/meminfo MemTotal: 65366332 kB MemFree: 20537144 kB MemAvailable: 21274804 kB HugePages_Total: 40 HugePages_Free: 40 HugePages_Rsvd: 0 HugePages_Surp: 0 3. Create a VM with 16G memory, no hugepages, run the VM on the host, load memory: # free -m total used free shared buff/cache available Mem: 15798 15200 392 8 205 324 Swap: 0 0 0 4. Check VDS_HIGH_MEM_USE warning in engine log: 2022-06-27 17:59:01,492+03 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-15) [] EVENT_ID: VDS_HIGH_MEM_USE(532), Used memory of host host_mixed_1 in cluster golden_env_mixed_1 [28%] exceeded defined threshold [50%]. Actual results: 1. The memory usage number in VDS_HIGH_MEM_USE warning is the total usage of normal memory and hugepages memory, which is 28% in the above case. Expected results: 1. The memory usage number in VDS_HIGH_MEM_USE warning should be the usage of normal memory which should be bigger than the defined threshold. Additional info:
Verified with: ovirt-engine-4.5.2-0.3.el8ev.noarch Steps: The same steps as in bug description. Result: The memory usage number in VDS_HIGH_MEM_USE warning is correct: WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-50) [] EVENT_ID: VDS_HIGH_MEM_USE(532), Used memory of host host_mixed_2 in cluster golden_env_mixed_1 [76%] exceeded defined threshold [50%].
This bugzilla is included in oVirt 4.5.2 release, published on August 10th 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.