Bug 1097987
| Summary: | [RFE][nova]: Virt driver pinning guest vCPUs to host pCPUs | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | RHOS Integration <rhos-integ> | |
| Component: | openstack-nova | Assignee: | Daniel Berrangé <berrange> | |
| Status: | CLOSED ERRATA | QA Contact: | Sean Toner <stoner> | |
| Severity: | low | Docs Contact: | ||
| Priority: | high | |||
| Version: | unspecified | CC: | ajeain, markmc, ndipanov, pablo.iranzo, sclewis, sgordon, slong, stoner, tvvcox, yeylon | |
| Target Milestone: | Upstream M2 | Keywords: | FutureFeature | |
| Target Release: | 7.0 (Kilo) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| URL: | https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning | |||
| Whiteboard: | upstream_milestone_kilo-2 upstream_definition_approved upstream_status_implemented | |||
| Fixed In Version: | openstack-nova-2014.2.1-7.el7ost | Doc Type: | Enhancement | |
| Doc Text: |
Compute can now provide dedicated CPU resources, where each guest virtual CPU has full access to a specific host CPU.
Previous releases of Compute guest CPUswere permitted to float across any host CPU. Even when the NUMA feature was enabled, the CPUs could still float within a NUMA node. Host CPUs would also overcommit so many virtual CPUs contended for the host resource. This made it impossible to provide strong performance guarantees to guest operating system workloads.
With this update, the cloud administrator now has the ability to set up a host aggregate, which provides a pool of hosts that supports guests with dedicated CPU resource assignment. The cloud administrator or tenant user can make use of these pools to run instances with guaranteed CPU resource.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1182818 (view as bug list) | Environment: | ||
| Last Closed: | 2015-02-09 14:57:48 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 743661, 799011, 1038706, 1077198, 1077204, 1182818 | |||
|
Description
RHOS Integration
2014-05-15 04:02:10 UTC
*** Bug 1077204 has been marked as a duplicate of this bug. *** Docs ==== Docs team should take a look at the upstream spec documents that are actually an excellent resource. First it would be good to consult the following 2 blueprints as the work done around CPU pinning uses it: http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno/implemented/virt-driver-vcpu-topology.rst http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno/implemented/virt-driver-numa-placement.rst The actual spec document for the cpu pinning work is here: http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/kilo/approved/virt-driver-cpu-pinning.rst The only majod difference between what is proposed in the spec being that hw:cpu_threads_policy extra_spec was not implemented and the behaviour follows what document describes as "prefer" Testing: === Here are some brief guidelines on testing, note that this functionality should really be tested together with rhbz #1057941 as they are extremely likely to be used together by majority of the users. * Create a host aggregate and add set metadata on it $ nova aggregate-create cpu_pinning $ nova aggregate-set-metadata 1 pinned=true * Create flavor that has extra spec "hw:cpu_policy" set to "dedicated" $ nova flavor-create pinned.medium 6 2048 20 2 $ nova flavor-key 6 set "hw:cpu_policy"="dedicated" $ nova flavor-key 6 set "aggregate_instance_extra_specs:pinned"="true" and set all other flavors to "aggregate_instance_extra_specs:pinned"="false" * Add a compute host to the created aggregate $ nova aggregate-add-host 1 ndipanov-devstack * Add proper filters to the scheduler_default_filters in /etc/nova.conf: scheduler_default_filters = RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter, ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter, AggregateInstanceExtraSpecsFilter,NUMATopologyFilter * After the above - with a normal (non-admin user) try to boot an instance with the newly created flavor $ nova boot --image fedora --flavor 6 test_pinning Things to test: * Confirm the instance has succesfully booted and that it's vCPU's are pinned to _a single_ host CPU by observing the <cputune> element of the generated domain XML * Confirm that after the host is "filled up" no other instances that require pinning get scheduler * Confirm that non-pinned instances never land on the host that is in the cpu_pinning aggregate (alternatively if it's the only host, instances with any other flavor should fail) After further testing - it seems that it is necessary to create at least 2 aggregates and make sure all hosts in the cloud are partitioned into them. After that it is necessary to: $ nova aggregate-set-metadata 2 pinned=false And as noted above it is necessary to make sure all non-pinned flavors also have "aggregate_instance_extra_specs:pinned"="false" NEEDINFO: Nikola Dipanov This bug is marked for inclusion in RHEA-2014:19421 [1] but does not currently contain draft documentation text. To ensure the timely release of this advisory, please provide draft documentation text for this bug as soon as possible. If you do not think this bug requires errata documentation, set the requires_doc_text flag to "-". To add draft documentation text: * Select the documentation type from the "Doc Type" drop down field. * A template will be provided in the "Doc Text" field based on the "Doc Type" value selected. Enter draft text in the "Doc Text" field. For further information on this process, refer to "Describing Errata Release and Technical Notes for Engineers" [2]. Thank you for your assistance! [1] https://errata.devel.redhat.com/advisory/19421 [2] https://engineering.redhat.com/docs/en-US/Policy/70.ecs/html/Describing_Errata_Release_and_Technical_Notes_for_Engineers/index.html Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0152.html |