SRIOV-CNI failed to load netconf about sriov-network-operator HOT 9 CLOSED

I do not understand why It try to get VF information from other NIC which is not I configured.

* Configured NIC : 0000:04:00.0

* Try to get from : 0000:05:00.1

0000:04:00.0 is the PF pci address.
The error message is from sriov-cni, it tries to get the PF interface name from 0000:05:00.1 device.
This 0000:05:00.1 pci address should come from kubelet which allocates the available VF device and eventually pass it down to sriov-cni.

Also one more thing is that I could not see "intel.com/intel-nics" when I execute command below:
$ kubectl get no -o json | jq -r '[.items[] | {name:.metadata.name, allocable:.status.allocatable}]'

you have the resource name defined as testsriov01 in the sriov node policy, so the openshift.io/testsriov01 is the resource name you should be looking for. it reports 9 available VF devices.

Do anyone have experience about this?

It looks like you have a mismatch between sriov node policy (numvfs: 2) and the actual reported device (9), there might be something wrong with vf provisioning. could you check how many vf devices are created on the worker node?

from sriov-network-operator.

Thanks for quick answer.
On the worker node, the 2 VFs were created as:

It seems something wrong during vf provisioning as you mentioned.

Actually, the way I deploy sriov-network-operator was clone from this git and build manually, not followed official document. (Because it does not work on my cluster)
Could this be reasons why error occurred?

from sriov-network-operator.

could you share the output of oc get configmap -n openshift-sriov-network-operator device-plugin-config -o yaml?
the namespace might be sriov-network-operator if you deployed the operator on vanilla k8s environment.

Also could you check which PF this device 0000:05:00.1 belongs to?

from sriov-network-operator.

Here is the output of oc get configmap -n openshift-sriov-network-operator device-plugin-config -o yaml.

The device 0000:05:00.1 is Physical Interface(PF), not a VF.

from sriov-network-operator.

Here is the output of oc get configmap -n openshift-sriov-network-operator device-plugin-config -o yaml.

The device 0000:05:00.1 is Physical Interface(PF), not a VF.

Ok, I think the issue is with above device plugin config map, it groups all the devices with same vendor IDs (8086) as a resource pool. so when you create a pod requesting device from that pool, it randomly chooses one (which happened to be the PF interface 0000:05:00.1), then sriov-cni failed to find PF name of that PF interface because sriov-cni only supports attaching VF device to pod.

You could try specify the pfNames in the sriov network node policy with the pf name of 0000:04:00.0 device.
Once the policy is successfully applied and the resource number is refreshed in node status, then re-creating the pod shall work as expected.

from sriov-network-operator.

I added pfName parameter on policy yaml file and re-create pod, then it successfully executed well.
Thank you for help.

However, I also test to attach the SRIOV on KubeVirt vmi. But it seems not work on KubeVirt.
Is there something more that I have to configure for KubeVirt?

The error case as:

KubeVirt yaml file as:

from sriov-network-operator.

I added pfName parameter on policy yaml file and re-create pod, then it successfully executed well.
Thank you for help.

However, I also test to attach the SRIOV on KubeVirt vmi. But it seems not work on KubeVirt.
Is there something more that I have to configure for KubeVirt?

The error case as:

KubeVirt yaml file as:

Comparing with what I tested, one difference is in the interfaces section: where I was using sriov, while above template uses bridge, not sure if that matters.

from sriov-network-operator.

Hi @rupang790 please take a look on the kubevirt sriov documentation https://kubevirt.io/user-guide/#/creation/interfaces-and-networks?id=sriov

from sriov-network-operator.

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from sriov-network-operator.