Bug 1318060 - Unable to utilize SR-IOV on multiple drivers or after changing drivers [NEEDINFO]
Summary: Unable to utilize SR-IOV on multiple drivers or after changing drivers
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 3.6.3.3
Hardware: x86_64
OS: Linux
unspecified
high vote
Target Milestone: ---
: ---
Assignee: Dan Kenigsberg
QA Contact: Meni Yakove
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-15 22:26 UTC by Jay Turner
Modified: 2016-04-14 07:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-14 07:43:00 UTC
oVirt Team: Network
danken: needinfo? (jturner)
ylavi: needinfo? (djorm)
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

Description Jay Turner 2016-03-15 22:26:26 UTC
Description of problem:
Two scenarios which seem to be related:
1) Have multiple SR-IOV enabled devices in a machine and attempt to utilize both device types (say having a Mellanox ConnectX-3 - mlx4 driver, along with an Intel XL710 - i40e driver).  oVirt will only recognize/utilize one of the two drivers.  For example, assigning the XL710 virtual function to a guest will result in the mlx4 driver being loaded in the guest as opposed to the i40e.
2) Once oVirt is installed with one SR-IOV device driver, you are not able to trade out for another device driver.  For example start off with the Mellanox device, then remove that device, clear everything out of oVirt, then put the Intel device in the host and attempt to utilize those VFs on new guests . . . oVirt will still assign/load the mlx4 driver even though the Mellanox card is no longer in the host.

In both scenarios, the only way to remedy the situation is to reinstall oVirt on the host.

Version-Release number of selected component (if applicable):
oVirt Engine Version: 3.6.3.4-1.el7.centos

How reproducible:
Always

Steps to Reproduce:
1. See above
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Dan Kenigsberg 2016-03-16 09:34:18 UTC
May I ask for a more detailed report, with smaller steps, as a I do not understand what have you done and which driver is wrongly selected.

Can you supply Vdsm logs with the output of getCapabilities and the logs until all VMs are up? In problem 1, do you run the same VM twice, connected to a different PF each time? Or are you running two different VMs concurrently?

can you provide the output of `lspci -vv` from within the VMs?

Comment 2 Dan Kenigsberg 2016-04-14 07:29:46 UTC
Please reopen when the requested information is available.


Note You need to log in before you can comment on or make changes to this bug.