Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1494956 - The scheduler does not engage memory balancing
Summary: The scheduler does not engage memory balancing
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 4.2.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact: Artyom
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-24 10:44 UTC by Artyom
Modified: 2017-10-30 14:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-30 14:22:53 UTC
oVirt Team: SLA


Attachments (Terms of Use)
engine log (8.12 MB, text/plain)
2017-09-24 10:44 UTC, Artyom
no flags Details

Description Artyom 2017-09-24 10:44:14 UTC
Created attachment 1330144 [details]
engine log

Description of problem:
The scheduler does not engage memory balancing

Version-Release number of selected component (if applicable):
ovirt-engine-4.2.0-0.0.master.20170921184504.gitfcfc9a7.el7.centos.noarch

How reproducible:
Always

Steps to Reproduce:
1. Start number of VM's on two hosts
==============================================================
host_1: has 2 VM's(one has 1Gb of memory and the second one has 12Gb of memory) and "Max free Memory for scheduling new VMs:
10220 MB"
==============================================================
host_2: has 3 VM's and "Max free Memory for scheduling new VMs:
5525 MB"
==============================================================
CPU consumption on each host around 3~4%
2. Choose power_saving policy under cluster parameters
Policy parameters:
HighUtilization: 75
LowUtilization: 35
HeSparesCount: 0
CpuOverCommitmentDuration: 1
MaxFreeMemoryForOverUtilized: 3606
MinFreeMemoryForUnderUtilized: 7702

3. Wait some time

Actual results:
Nothing happens

Expected results:
Scheduler must migrate VM with 1Gb of memory from host_1 to host_2

Additional info:
Under the engine log the single thing that I can see:
017-09-24 13:42:32,462+03 DEBUG [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (EE-ManagedThreadFactory-engineScheduled-Thread-77) [] Load Balancer timer entered.
2017-09-24 13:42:32,477+03 WARN  [org.ovirt.engine.core.bll.scheduling.policyunits.CpuAndMemoryBalancingPolicyUnit] (EE-ManagedThreadFactory-engineScheduled-Thread-77) [] All candidate hosts have been filtered, can't balance the cluster 'golden_env_mixed_1' based on the CPU usage, will try memory based approach
2017-09-24 13:42:32,510+03 INFO  [org.ovirt.engine.core.bll.scheduling.policyunits.PowerSavingBalancePolicyUnit] (EE-ManagedThreadFactory-engineScheduled-Thread-77) [] Automatic power management is disabled for cluster 'golden_env_mixed_1'.
2017-09-24 13:42:39,721+03 INFO  [org.ovirt.engine.core.bll.storage.ovfstore.OvfDataUpdater] (EE-ManagedThreadFactory-engineScheduled-Thread-3) [] Attempting to update VMs/Templates Ovf.
...

Comment 2 Doron Fediuck 2017-10-26 14:25:06 UTC
Artyom can you please provide a debug log?

Comment 3 Martin Sivák 2017-10-26 15:14:57 UTC
Also, can you please describe the other VMs you have in the cluster?

Comment 4 Martin Sivák 2017-10-26 19:53:40 UTC
I just ran the numbers from the bug report through our balancing unit test and the code properly selects the 1GB VM from host_1 for migration to host_2.

We really need the debug log to see why the migration was not performed. Please enable debug for the whole org.ovirt.engine.core.bll.scheduling package if you are going to do that selectively.

Comment 5 Artyom 2017-10-29 06:44:59 UTC
The log includes all DEBUG logs from org.ovirt.engine.core.bll.scheduling, so nothing new to add.
I will recheck if it works on the latest nightly build.

Comment 6 Artyom 2017-10-30 14:22:53 UTC
I checked the policies on the build ovirt-engine-4.2.0-0.0.master.20171027213842.gitded437c.el7.centos.noarch and looks like all works as expected. I will close the bug for now and will reopen it in the case if I will encounter the above behavior again.


Note You need to log in before you can comment on or make changes to this bug.