Bug 1859182

Summary: Unable to create VMs with SR-IOV VF when NIC Partitioning is used
Product: Red Hat OpenStack Reporter: Karthik Sundaravel <ksundara>
Component: openstack-tripleoAssignee: Karthik Sundaravel <ksundara>
Status: CLOSED ERRATA QA Contact: nlevinki <nlevinki>
Severity: medium Docs Contact:
Priority: medium    
Version: 16.1 (Train)CC: drosenfe, hakhande, mburns, mnietoji, supadhya, vkhitrin
Target Milestone: z2Keywords: Triaged
Target Release: 16.1 (Train on RHEL 8.2)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1862052 1873109 (view as bug list) Environment:
Last Closed: 2020-10-28 15:38:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1862052, 1873109    

Description Karthik Sundaravel 2020-07-21 12:01:03 UTC
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"

Comment 1 Karthik Sundaravel 2020-07-21 12:10:48 UTC
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"}}

Comment 2 Karthik Sundaravel 2020-07-21 12:13:29 UTC
(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"}}

Comment 6 Sanjay Upadhyay 2020-10-08 09:37:57 UTC
Manually moving to on_qa, this is already verified.

Comment 12 errata-xmlrpc 2020-10-28 15:38:25 UTC
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