Comment 14 for bug 1616442

This is the contents of the aforementioned google docs that was referenced in this BZ in error. Sorry, I should've rectified it sooner. I was reminded by yet another request for access. While it has been edited some, it was only meant to reflect general steps. Accuracy/correctness not guaranteed.

Configuration
-------------

This describes a general configuration of OpenStack services to support PCI SR-IOV. It currently does not extend to creating node preparation, creation of neutron networks, etc. Services that have had their configuration modified will need to be restarted.

Controller Node
---------------

Nova
- Ensure that the PciPassthroughFilter is listed in scheduler_default_filters in nova.conf.

Neutron
- add sriovnicswitch to the list of mechanism_drivers to ML2 configuration (e.g /etc/neutron/plugins/ml2/ml2_conf.ini)
- add vendor device entry to [ml2_sriov]/supported_pci_vendor_devs to ML2 configuration e.g.: supported_pci_vendor_devs = 8086:154d, 8086:10ed

Compute Node

Nova
- For the pci_passthrough_whitelist, use the from [{“vendor_id”:”vendor_id_value”, “product_id”:”product_id_value”, “physical_network”:”physical_network_label”}]. Note the product ID for physical functions and virtual functions is different. If you wish to configure support for both on a node, you will need two separate entries.
For example: /etc/nova/nova.conf
pci_passthrough_whitelist =[{"vendor_id":"8086", "product_id":"154d", "physical_network":"physnet"}, {"vendor_id":"8086", "product_id":"10ed", "physical_network":"physnet"} ]

Clarifications and known issues:
Some documentation states that you need to specify device_type=”type-PF”. This is only required if you use the “alias” method for device allocation.
While using devname seems to work fine for virtual functions, it does not seem to work for physical functions

Neutron
   For PFs, the SRIOV agent does not need any additional configuration.

(The original document references erroneously configuring the sriov agent with the physical function. This is bogus since the agent isn't meant to manage physical functions. There is an issue though if a physical function is allocated as the virtual functions that the agent *does* know about)