Upstream bug: https://bugs.launchpad.net/nova/+bug/1582278
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>
fixes for stable/mitaka: https:/
will wait for merge and for sync with stable/mitaka