Bug 1369768
Summary: | [RFE] [Neutron] SRIOV agent does not allow the co-existence of VF and PF on the same node | |||
---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Eran Kuris <ekuris> | |
Component: | openstack-neutron | Assignee: | Brent Eagles <beagles> | |
Status: | CLOSED ERRATA | QA Contact: | Yariv <yrachman> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 10.0 (Newton) | CC: | amuller, atelang, beagles, chrisw, ekuris, fbaudin, jjung, jlibosva, jschluet, ksundara, nyechiel, oblaut, rnoriega, srevivo, tvvcox, yrachman, zgreenbe | |
Target Milestone: | z3 | Keywords: | FutureFeature, Triaged, ZStream | |
Target Release: | 10.0 (Newton) | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | openstack-neutron-9.2.0-5.el7ost | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1392584 (view as bug list) | Environment: | ||
Last Closed: | 2017-06-28 15:31:11 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: | 1235009, 1392584, 1392585 |
Description
Eran Kuris
2016-08-24 11:28:32 UTC
Following the upstream Launchpad bug, this is only relevant if we intend to allow users to create both VFs and PFs on the same node. Is that functionality relevant and required? If so this RHBZ should indeed block the RFE, otherwise it shouldn't, I'll leave that decision up to you. (In reply to Assaf Muller from comment #2) > Following the upstream Launchpad bug, this is only relevant if we intend to > allow users to create both VFs and PFs on the same node. Is that > functionality relevant and required? If so this RHBZ should indeed block the > RFE, otherwise it shouldn't, I'll leave that decision up to you. Eran/Assaf: I am not sure I am following. Once you enable PF, no VFs will be available to do SR-IOV. And once you enable a single VF, the PF won’t be available anymore in the card. So what do you mean by "allow users to create both VFs and PFs on the same node"? Are you referring to using VFs and PFs on the same host but from separate network adapters? Thanks, Nir Yes Nir this is exactly what I meant. Also there is scenario that Network adapter is already configured with VFs and after that I want to change it to work with all PF after I disassociate all ports from VFs. (In reply to Eran Kuris from comment #4) > Yes Nir this is exactly what I meant. > Also there is scenario that Network adapter is already configured with VFs > and after that I want to change it to work with all PF after I disassociate > all ports from VFs. And just to understand this bug - you are saying that this is working, but the agent log shows errors? Thanks, Nir (In reply to Nir Yechiel from comment #5) > (In reply to Eran Kuris from comment #4) > > Yes Nir this is exactly what I meant. > > Also there is scenario that Network adapter is already configured with VFs > > and after that I want to change it to work with all PF after I disassociate > > all ports from VFs. > > And just to understand this bug - you are saying that this is working, but > the agent log shows errors? > > Thanks, > Nir You are correct Thanks for the clarifications, Eran. @Assaf, the use case is valid and we should look at the upstream bug. But since the functionally is there this should not be treated as a high priority bug or block the RHOSP 10 RFE, IMO. Thanks, Nir Hello guys, I'm having the same stacktrace from the SRIOV agent, but I think there is indeed an issue. Let's say a compute node has got 2 network adapters (em1 and em2) with its correspondent VFs configured. If you start a VM with a direct-physical binding it will take one of these NICs. At that moment, SRIOV agent starts to show those ERROR messages including the "device dictionary" completely empty. In consequence, you cannot allocate VMs with VFs eventhough there is still another NIC available. IMHO, until this issue is not fixed, coexistence of VFs/PFs won't be usable. @Nir, could you reconsider the priority of this issue?? Thanks! (In reply to Ricardo Noriega from comment #8) > Hello guys, > > I'm having the same stacktrace from the SRIOV agent, but I think there is > indeed an issue. > > Let's say a compute node has got 2 network adapters (em1 and em2) with its > correspondent VFs configured. If you start a VM with a direct-physical > binding it will take one of these NICs. At that moment, SRIOV agent starts > to show those ERROR messages including the "device dictionary" completely > empty. > > In consequence, you cannot allocate VMs with VFs eventhough there is still > another NIC available. > > IMHO, until this issue is not fixed, coexistence of VFs/PFs won't be usable. > > @Nir, could you reconsider the priority of this issue?? Thanks! You'll have to excuse my cheekyness but I'm going to steal your comment and post it in the Launchpad bug. (In reply to Assaf Muller from comment #9) > (In reply to Ricardo Noriega from comment #8) > > Hello guys, > > > > I'm having the same stacktrace from the SRIOV agent, but I think there is > > indeed an issue. > > > > Let's say a compute node has got 2 network adapters (em1 and em2) with its > > correspondent VFs configured. If you start a VM with a direct-physical > > binding it will take one of these NICs. At that moment, SRIOV agent starts > > to show those ERROR messages including the "device dictionary" completely > > empty. > > > > In consequence, you cannot allocate VMs with VFs eventhough there is still > > another NIC available. > > > > IMHO, until this issue is not fixed, coexistence of VFs/PFs won't be usable. > > > > @Nir, could you reconsider the priority of this issue?? Thanks! > > You'll have to excuse my cheekyness but I'm going to steal your comment and > post it in the Launchpad bug. Your cheekyness is excused. No prob. With: https://review.openstack.org/#/c/360447 and a modified version of (as per comments provided in review) https://review.openstack.org/#/c/377781/ A udev rule to call a script to set the vf count I got really close to co-existence. In the absence of NetworkManager, I need to add a script to be called from /proc/sys/kernel/hotplug to set the SR-IOV's link status to "up" before I could allocate VFs. At the moment, I can flip back and forth using a device as a PF or as VFs. With both PFs enabled, I can also use one for VFs and the other as a PF. We'll have to examine if this is route that. Obviously adding supporting scripting, etc. is outside the scope this bug and what we can expect from a user, but I mention it to outline a.) how I tested the patches and b.) what we might need to add to tripleo for supporting this functionality. Now all we need to do is to help these patches along to get merged u/s. I'm moving this back from 11 to 10.z. If we find that we cannot backport the fix to 10 for whatever reason we'll think about this again. stable/newton patch is proposed to upstream https://review.openstack.org/#/c/442088 It was verified in puddle 2017-06-15.5 The /var/log/neutron/sriov-nic-agent.log is clean without any errors. 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, 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/RHBA-2017:1594 |