Bug 1695037

Summary:	[SR-IOV] Support 'i40e' driver
Product:	[oVirt] vdsm	Reporter:	Michael Burman <mburman>
Component:	Core	Assignee:	Ales Musil <amusil>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Michael Burman <mburman>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.30.10	CC:	amusil, bugs, danken, dholler
Target Milestone:	ovirt-4.3.5
Target Release:	4.30.23
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	v4.30.23	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-07-30 14:08:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1701191
Bug Blocks:

Description Michael Burman 2019-04-02 11:10:19 UTC

Description of problem:
[SR-IOV] Support 'i40e' driver

Hi, we have new hosts with SR-IOV capabilities and their driver is 'i40e'.
We don't support this driver and entire sr-iov test plan is failing. 
There is a VF leakage on the host once VFs are enabled on them.

Version-Release number of selected component (if applicable):
vdsm-4.30.11-1.el7ev.x86_64

How reproducible:
100% on SR-IOV host Dell PowerEdge C6420 with i40e

Steps to Reproduce:
1. Enable 1 VF on the host
2. Edit the PF and change the num of vfs to 2 

Actual results:
Engine consider the previous VF as used 
"enp179s0f1:
Cannot edit host NIC VFs configuration. The selected network interface enp179s0f1 has VFs that are in use."

Expected results:
Should work as expected. 

Additional info:
This is now blocking us from running SR-IOV tests on this new HW

Comment 3 Ales Musil 2019-04-02 14:04:40 UTC

> Steps to Reproduce:
> 1. Enable 1 VF on the host
> 2. Edit the PF and change the num of vfs to 2 
> 


Hi Michael,

can you try "Refresh capabilities" between step one and two? 
It seems that this resolves the issue for me locally. 

If so there is probably bug that we are not refresh caps after setup networks.

Comment 4 Michael Burman 2019-04-03 04:28:48 UTC

(In reply to Ales Musil from comment #3)
> > Steps to Reproduce:
> > 1. Enable 1 VF on the host
> > 2. Edit the PF and change the num of vfs to 2 
> > 
> 
> 
> Hi Michael,
> 
> can you try "Refresh capabilities" between step one and two? 
> It seems that this resolves the issue for me locally. 
It is. 
> 
> If so there is probably bug that we are not refresh caps after setup
> networks.
But, this is happens only with this specific HW, all other our SR-IOV HW doesn't behave this way, is it related to this specific driver? seems like it is.

Comment 5 Michael Burman 2019-04-10 08:18:03 UTC

Should i expect the fix in 4.3.5?

Comment 6 Dominik Holler 2019-04-10 08:57:56 UTC

Ales is already working on it during this sprint, but it seems to be not straight to fix and the most helpful reviewer is not really available.
If you would accept it, there is a chance to get this fix into 3.4.3.

Comment 7 Michael Burman 2019-04-10 09:06:44 UTC

(In reply to Dominik Holler from comment #6)
> Ales is already working on it during this sprint, but it seems to be not
> straight to fix and the most helpful reviewer is not really available.
> If you would accept it, there is a chance to get this fix into 3.4.3.

3.4.3 ?

Comment 8 Dominik Holler 2019-04-10 09:08:29 UTC

(In reply to Michael Burman from comment #7)
> (In reply to Dominik Holler from comment #6)
> > Ales is already working on it during this sprint, but it seems to be not
> > straight to fix and the most helpful reviewer is not really available.
> > If you would accept it, there is a chance to get this fix into 3.4.3.
> 
> 3.4.3 ?

sorry, 4.3.4

Comment 9 Michael Burman 2019-04-10 09:09:29 UTC

I would like to get this fix ASAP, so 4.3.4 is ok for me.

Comment 11 Michael Burman 2019-07-08 09:02:51 UTC

Verified on - vdsm-4.30.23-2.el7ev.x86_64 and 
4.3.5.3-0.1.el7
kernel 3.10.0-1060.el7.x86_64 which includes the fix for BZ 1701191

Comment 12 Sandro Bonazzola 2019-07-30 14:08:12 UTC

This bugzilla is included in oVirt 4.3.5 release, published on July 30th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.5 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.