1. What is the nature and description of the request? A new property is requested for evenly_distributed policy, in addition to the current ones, that takes in account also the virtualCPUs/physicalCPUs ratio , to produce automatic VMs live migration in case of a ratio greater than a proper value (possible values: decimal number in the range 0.1 - 2.5) This would allow to avoid CPU overcommit and rebalance the loads. 2. Why would you need this? (List the business requirements here) During RHV cluster upgrade or other workload rebalance situation, is important for CPU intensive workloads to avoid CPU overcommit on each hypervisor. 3. How would you like to achieve this? (List the functional requirements here) Add a new property in the evenly_distributed policy named "virtualCPUs/physicalCPUs ratio" to accept decimal number values in the range 0.1 - 2.5 4. For each functional requirement listed, specify how you can test to confirm the requirement is successfully implemented. - Create cluster with 2 hypervisor - the 2 nodes (A and B) have 1 dual core CPU per each - Set the "virtualCPUs/physicalCPUs ratio" property in the evenly_distributed policy to 1.5 - Create new 4 VMs and start all of them on node A - Scheduler should start only 3 VMs on A, 4th should start on node B 5. Do you have any specific timeline dependencies ? As soon as possible 6. Would you be able to assist in testing this functionality if implemented? yes
Lucia, can you please add documentation for this?
Verified on: Software Version:4.5.0.4-0.1.el8ev Tested with 2 hosts in a cluster, each host has 32 CPUs and each VM 12 vCPUs. Using 4 VMs. When cluster policy set to "evenly_distributed", VCpuToPhysicalCpuRatio set to 1.25 and Specific Host set all 4 VMs start on this specific host, shortly after, one of the VMs migrates to the other host as intended.
Apr 28, 2022, 2:17:21 PM Migration completed (VM: vm1, Source: host1, Destination: host2, Duration: 6 seconds, Total: 6 seconds, Actual downtime: (N/A)) Apr 28, 2022, 2:17:14 PM Migration initiated by system (VM: vm1, Source: host1, Destination: host2, Reason: Load balancing). Apr 28, 2022, 2:17:03 PM VM vm2 started on Host host1 Apr 28, 2022, 2:17:03 PM VM vm1 started on Host host1 Apr 28, 2022, 2:17:03 PM VM vm4 started on Host host1 Apr 28, 2022, 2:17:03 PM VM vm3 started on Host host1
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
Due to QE capacity, we are not going to cover this issue in our automation