Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
When we allocate CPUs we are basing upon the list we return back. This is correct for the scheduling phase. But now we run the same logic on canSchedule. There, when having a group of VMs, we are basing on the cpuTopology list, not the list we selected to allocate. The overtaken CPU wasn't released from the pinning itself and that harmed the canSchedule logic for VM groups. Also, when grouping the VMs, when the group is having an affinity set, it is reordered. Therefore, it is required to sort them there as well. Change-Id: Idcae90fed953c4798f2c4bf8893bff0a1b7086ea Signed-off-by: Liran Rotenberg <lrotenbe@redhat.com>
- Loading branch information