Bug 1569107

Summary:	When instance has pinned cpus in a given numa zone, evacuation will try to schedule the same cpus/numa zone on another compute
Product:	Red Hat OpenStack	Reporter:	David Hill <dhill>
Component:	openstack-nova	Assignee:	OSP DFG:Compute <osp-dfg-compute>
Status:	CLOSED NOTABUG	QA Contact:	OSP DFG:Compute <osp-dfg-compute>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	10.0 (Newton)	CC:	berrange, dasmith, dhill, eglynn, jhakimra, kchamart, sbauza, sferdjao, sgordon, srevivo, vromanso
Target Milestone:	---	Keywords:	ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-04-26 23:36:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Hill 2018-04-18 15:43:42 UTC

Description of problem:
When instance has pinned cpus in a given numa zone, evacuation will try to schedule the same cpus/numa zone on another compute and this will fail if the same cpus/numa zone is taken .    If the cpus / numa zone are free, scheduling will pass and the VM will actually be rebuilt on the new compute.  It looks like NUMAToplogyFilter tries to find the same topology on a different host.

This is when hw:cpu_policy=dedicated is being used.   We feel like this is a bug.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 10 Artom Lifshitz 2018-04-26 23:36:25 UTC

Based on our IRC conversations, I'm closing this as NOTABUG for now. It looks like the NUMA topology filter was correct after all in thinking that not enough CPUs were available. If this turns out not to be the case, by all means reopen this bug.