support set vcpu topology in libvirt driver by image property 'hw_cpu_topology'
The discussion thread is here: http://
The wikipage is here: https:/
Currently libvirt config the topology of an instance
with the sockets equal to the vcpus, and set both cores
and threads to 1 by default. But some operating systems
(especially windows os)only support a few sockets, this
results in the users do not get the same number of vcpus
as the flavor they used for creating their instances.
So the 'hw_cpu_topology' image property is added here,
and it supports config max sockets, max cores and max threads number
of the image like this 'max_sockets:
where max_cores means max cores per socket, max_threads
means max threads per core.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- wangpan
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Needs Code Review
- Milestone target:
- None
- Started by
- Russell Bryant on 2013-11-19
- Completed by
- wangpan on 2014-03-21
Related branches
Related bugs
Sprints
Whiteboard
Deferred to icehouse-3 as the blueprint was not approved by the icehouse-2 blueprint approval deadline. --russellb
Gerrit topic: https:/
Addressed by: https:/
libvirt: Support config cpu topology through image
Related discussion: http://
Addressed by: https:/
Add support for user-defined CPU topologies
deferred from icehouse-3 to "next": http://
The subject of vCPU topology is very closely tied up with NUMA placement, as such I think we need to consider any design of this blueprint in co-ordination with https:/
Removed from next, as next is now reserved for near misses from the last milestone --johnthetubagu
Gerrit topic: https:/
Addressed by: https:/
libvirt: Support config cpu topology through image
Related discussion: http://
Addressed by: https:/
Add support for user-defined CPU topologies
deferred from icehouse-3 to "next": http://
The subject of vCPU topology is very closely tied up with NUMA placement, as such I think we need to consider any design of this blueprint in co-ordination with https:/
Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy
Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)
Abandon this and Daniel has opened a new one: https:/
Work Items
Dependency tree
* Blueprints in grey have been implemented.
