Comment 0 for bug 1581471

Detailed bug description:
 Instances on sr-iov port with flavor for pinning doesn't work proper: in most cases we have an error state for vm after boot

Steps to reproduce:
 1) Deploy env with SR-IOV and CPU pinning enable
 2) Create aggregates for cpu pinning:
nova aggregate-create performance
nova aggregate-set-metadata performance pinned=true
nova aggregate-add-host performance node-2.test.domain.local
nova aggregate-add-host performance node-3.test.domain.local
nova aggregate-add-host performance node-4.test.domain.local
nova aggregate-add-host performance node-5.test.domain.local
 3) Create new flavor:
nova flavor-show m1.small.performance
+----------------------------+-------------------------------------------------------------------------------------------------------+
| Property | Value |
+----------------------------+-------------------------------------------------------------------------------------------------------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 20 |
| extra_specs | {"aggregate_instance_extra_specs:pinned": "true", "hw:cpu_policy": "dedicated", "hw:numa_nodes": "1"} |
| id | 7b0e5ee0-0bf7-4a46-9653-9279a947c650 |
| name | m1.small.performance |
| os-flavor-access:is_public | True |
| ram | 2048 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 1 |
+----------------------------+--------------------------------------------------------------------------------
 4) download ubuntu image
 5) create sr-iov port and boot vm on this port with m1.small.performance flavor:
NODE_1='node-4.test.domain.local'
NODE_2='node-5.test.domain.local'
NET_ID_1=$(neutron net-list | grep net_EW_2 | awk '{print$2}')
neutron port-create $NET_ID_1 --binding:vnic-type direct --device_owner nova-compute --name sriov_23
port_id=$(neutron port-list | grep 'sriov_23' | awk '{print$2}')
nova boot vm23 --flavor m1.small.performance --image ubuntu_image --availability-zone nova:$NODE_1 --nic port-id=$port_id --key-name vm_key

Expected results:
 VM is an ACTIVE state
Actual result:
 In most cases the state is ERROR. Sometimes we can boot vms without zones but they very rarely is an ACTIVE state

Description of the environment:
 iso #312, 9.0, neutron+vlan. 1 controller, 4 compute:
- 2 computesr-iov+hp+cpu pinning
- cpu pinning + hp
- cpu pinning

shotgun2 short-report
cat /etc/fuel_build_id:
 312
cat /etc/fuel_build_number:
 312
cat /etc/fuel_release:
 9.0
cat /etc/fuel_openstack_version:
 mitaka-9.0
rpm -qa | egrep 'fuel|astute|network-checker|nailgun|packetary|shotgun':
 fuel-release-9.0.0-1.mos6344.noarch
 network-checker-9.0.0-1.mos72.x86_64
 fuel-mirror-9.0.0-1.mos135.noarch
 fuel-openstack-metadata-9.0.0-1.mos8681.noarch
 fuel-notify-9.0.0-1.mos8338.noarch
 fuel-ostf-9.0.0-1.mos934.noarch
 python-fuelclient-9.0.0-1.mos313.noarch
 fuelmenu-9.0.0-1.mos270.noarch
 fuel-9.0.0-1.mos6344.noarch
 fuel-utils-9.0.0-1.mos8338.noarch
 fuel-nailgun-9.0.0-1.mos8681.noarch
 rubygem-astute-9.0.0-1.mos742.noarch
 fuel-misc-9.0.0-1.mos8338.noarch
 fuel-library9.0-9.0.0-1.mos8338.noarch
 shotgun-9.0.0-1.mos88.noarch
 fuel-agent-9.0.0-1.mos276.noarch
 fuel-ui-9.0.0-1.mos2678.noarch
 fuel-setup-9.0.0-1.mos6344.noarch
 nailgun-mcagents-9.0.0-1.mos742.noarch
 fuel-provisioning-scripts-9.0.0-1.mos8681.noarch
 python-packetary-9.0.0-1.mos135.noarch
 fuel-bootstrap-cli-9.0.0-1.mos276.noarch
 fuel-migrate-9.0.0-1.mos8338.noarch
- Operation system: <put your information here>
- Versions of components: <put your information here>
- Reference architecture: <put your information here>
- Network model: <put your information here>
- Related projects installed: <put your information here>