Templates: NovaPCIPassthrough: - devname: "p7p3" trusted: "true" physical_network: "sriov-1" - devname: "p7p4" trusted: "true" physical_network: "sriov-2" - devname: "p6p1" trusted: "true" NeutronPhysicalDevMappings: - sriov-1:p7p3 - sriov-2:p7p4 The NIC configs uses NIC partitioning on p7p3 and p7p4, with VFs 0 and 1 each. The guests are created using the below commands openstack network create sriov1 --provider-network-type vlan --provider-physical-network sriov1 --provider-segment 502 openstack subnet create sriov1 --subnet-range 192.168.3.0/24 --network sriov1 openstack port create sriov1 --network sriov1 --vnic-type direct sriov1_port=$(openstack port show sriov1 -c id -f value) openstack server create --flavor m1.nfv --image rhel_nfv --nic port-id=$sriov1_port --key-name test sriov11 The guest sriov11 is in error state due to "No valid host found"
Its found that the passthrough_whitelist generated in nova.conf has the PCI addresses of the applicable VFs, their vendor id and product ids. However we find that with physical_network details, nova could reserve a VF and the guest creation is possible. The below configuration works and the corresponding patch shall be made in pci_passthrough_whitelist.json passthrough_whitelist={"physical_network":"sriov-10","trusted":"true","address":{"slot":"02","bus":"82","domain":".*","function":"0"}} passthrough_whitelist={"physical_network":"sriov-10","trusted":"true","address":{"slot":"02","bus":"82","domain":".*","function":"1"}} passthrough_whitelist={"physical_network":"sriov-10","trusted":"true","address":{"slot":"02","bus":"82","domain":".*","function":"2"}} passthrough_whitelist={"physical_network":"sriov-10","trusted":"true","address":{"slot":"02","bus":"82","domain":".*","function":"3"}} passthrough_whitelist={"physical_network":"sriov-10","trusted":"true","address":{"slot":"02","bus":"82","domain":".*","function":"4"}} passthrough_whitelist={"physical_network":"sriov-10","trusted":"true","address":{"slot":"02","bus":"82","domain":".*","function":"5"}} passthrough_whitelist={"physical_network":"sriov-20","trusted":"true","address":{"slot":"06","bus":"82","domain":".*","function":"0"}} passthrough_whitelist={"physical_network":"sriov-20","trusted":"true","address":{"slot":"06","bus":"82","domain":".*","function":"1"}} passthrough_whitelist={"physical_network":"sriov-20","trusted":"true","address":{"slot":"06","bus":"82","domain":".*","function":"2"}} passthrough_whitelist={"physical_network":"sriov-20","trusted":"true","address":{"slot":"06","bus":"82","domain":".*","function":"3"}} passthrough_whitelist={"physical_network":"sriov-20","trusted":"true","address":{"slot":"06","bus":"82","domain":".*","function":"4"}} passthrough_whitelist={"physical_network":"sriov-20","trusted":"true","address":{"slot":"06","bus":"82","domain":".*","function":"5"}}
(In reply to Karthik Sundaravel from comment #1) > Its found that the passthrough_whitelist generated in nova.conf has the PCI > addresses of the applicable VFs, their vendor id and product ids. > > However we find that with physical_network details, nova could reserve a VF > and the guest creation is possible. > The below configuration works and the corresponding patch shall be made in derive_pci_passthrough_whitelist.py > > passthrough_whitelist={"physical_network":"sriov-10","trusted":"true", > "address":{"slot":"02","bus":"82","domain":".*","function":"0"}} > passthrough_whitelist={"physical_network":"sriov-10","trusted":"true", > "address":{"slot":"02","bus":"82","domain":".*","function":"1"}} > passthrough_whitelist={"physical_network":"sriov-10","trusted":"true", > "address":{"slot":"02","bus":"82","domain":".*","function":"2"}} > passthrough_whitelist={"physical_network":"sriov-10","trusted":"true", > "address":{"slot":"02","bus":"82","domain":".*","function":"3"}} > passthrough_whitelist={"physical_network":"sriov-10","trusted":"true", > "address":{"slot":"02","bus":"82","domain":".*","function":"4"}} > passthrough_whitelist={"physical_network":"sriov-10","trusted":"true", > "address":{"slot":"02","bus":"82","domain":".*","function":"5"}} > passthrough_whitelist={"physical_network":"sriov-20","trusted":"true", > "address":{"slot":"06","bus":"82","domain":".*","function":"0"}} > passthrough_whitelist={"physical_network":"sriov-20","trusted":"true", > "address":{"slot":"06","bus":"82","domain":".*","function":"1"}} > passthrough_whitelist={"physical_network":"sriov-20","trusted":"true", > "address":{"slot":"06","bus":"82","domain":".*","function":"2"}} > passthrough_whitelist={"physical_network":"sriov-20","trusted":"true", > "address":{"slot":"06","bus":"82","domain":".*","function":"3"}} > passthrough_whitelist={"physical_network":"sriov-20","trusted":"true", > "address":{"slot":"06","bus":"82","domain":".*","function":"4"}} > passthrough_whitelist={"physical_network":"sriov-20","trusted":"true", > "address":{"slot":"06","bus":"82","domain":".*","function":"5"}}
Manually moving to on_qa, this is already verified.
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 (Red Hat OpenStack Platform 16.1 bug fix and enhancement 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://access.redhat.com/errata/RHEA-2020:4284