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
> 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.
(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.
Should i expect the fix in 4.3.5?
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.
(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 ?
(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
I would like to get this fix ASAP, so 4.3.4 is ok for me.
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
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.