Bug 1295204

Summary: Scheduling CPU filter doesn't take the new "thread-per-core" value in consideration
Product: [oVirt] ovirt-engine Reporter: sefi litmanovich <slitmano>
Component: Backend.CoreAssignee: Nobody <nobody>
Status: CLOSED DUPLICATE QA Contact: Aharon Canan <acanan>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.6.2CC: bugs, slitmano
Target Milestone: ---Flags: slitmano: planning_ack?
slitmano: devel_ack?
slitmano: testing_ack?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: sla
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-06 13:39:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: SLA RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description sefi litmanovich 2016-01-03 14:04:17 UTC
Description of problem:

As a result of bz: https://bugzilla.redhat.com/show_bug.cgi?id=1267165 a new "thread per core" parameter was added to vm's system configurations.
It seems though that when scheduler checks vm's CPU it only multiplies Virtual_sockets * core_per_virtual_scoket but ignores threads_per_core.
Due to this problem I was able e.g. to run on a host with:
8 CPUS = 1_socket * 4_cores_per_socket * 2_threads_per_core..
a vm with a total of 16 Virtual CPU = 2_virtual_sockets * 1_core_per_socket * 8_threads_per_core.
running this vm was not blocked due to scheduling filter (policy is default=None with CPU filter).
When I edited the vm and kept 16 Virtual CPUs but this time with 8 cores_per_socket and 1 threads_per_core (keeping 2 virutal sockets), when trying to run the vm I did get the expected scheduling filter error.

Version-Release number of selected component (if applicable):

rhevm-3.6.2-0.1.el6.noarch

How reproducible:

always

Steps to Reproduce:
1. say you have a cluster with a host of 8 CPU, cluster scheduling policy set to None(Default).
2. create a vm -> in system tab set:
Virtual CPU = 16
virtual_sockets = 2
core_per_socket = 1
threads_per_core = 8
3. run vm.

Actual results:

Vm starts normally.

Expected results:

Vm doesn't start, a message regarding no host satisfying scheduling policy should be invoked.

Comment 1 Yaniv Kaul 2016-01-04 07:56:11 UTC
Dup of bug 1295203 ?

Comment 2 Gil Klein 2016-01-06 13:39:48 UTC

*** This bug has been marked as a duplicate of bug 1295203 ***