Red Hat Bugzilla – Bug 1097987
[RFE][nova]: Virt driver pinning guest vCPUs to host pCPUs
Last modified: 2017-08-18 05:36:12 EDT
Cloned from launchpad blueprint https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning. Description: This feature aims to improve the libvirt driver so that it is able to strictly pin guest vCPUS to host pCPUs. This provides the concept of "dedicated CPU" guest instances. Specification URL (additional information): None
*** 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