Description of problem: Current implementation of the Physical Function (PF) passthrough lacks any network awareness. It is exposing the physical hardware to the instances without an integration with Neutron, unlike the way it is implemented for the SR-IOV Virtual Functions (VFs). Workloads requiring to have full access to a physical function will also need to have the ability to manipulate the network settings, in the same manner and flexibility that is currently available for VFs.
Can you please fill in the doctext? Thank you.
resetting Fixed in version to osp 9 build
Hi Brent , please take a look on this test plan , I would like get your comments before I start to run the tests . If you think I need to add / remove something please let me know. https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/workitem?id=RHELOSP-15921 Also I would to know how can I check the PF attached to instance? should I see it in : ip link show ? thanks
Final test plan : https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/workitem?id=RHELOSP-16120 https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/workitem?id=RHELOSP-16121 https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/workitem?id=RHELOSP-16122 https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/workitem?id=RHELOSP-16123
After I check the RFE I found few bugs . I attached all relevant bugs and assign it to DEV .
With respect to blockers for this RFE, I suggest that: Configuring system so that PFs work: https://bugzilla.redhat.com/show_bug.cgi?id=1367790 https://bugzilla.redhat.com/show_bug.cgi?id=1367263 https://bugzilla.redhat.com/show_bug.cgi?id=1369768 I believe there is some overlap. In general the documented mechanisms for configuring PFs have issues. It can be said that there is a workaround because as long as you configure things a specific way, things will work. Unfortunately, the syntax that does work might end up including PCI devices that an administrator doesn't want used. That is, the working syntax isn't specific enough. The other aspect is that there may be issues with the SR-IOV agent when a PF is allocated as the VFs "disappear". I don't think it crashes, but of any issue referenced, this one gives the me the most pause. In short, I don't think these are really blockers, but as a group VLAN-id https://bugzilla.redhat.com/show_bug.cgi?id=1367786 IIUC this was not a use case covered by the intended scope of the current implementation. So this is more of an additional feature/functionality than a blocker Setting numvfs to 0 https://bugzilla.redhat.com/show_bug.cgi?id=1370047 This is basically the SR-IOV agent being configured to monitor something that we are removing the VFs from but leaving the bare interface there. FWICT, we don't need to, and should not, be setting numvfs to 0. If we intend something to be used as PF only, the SR-IOV agent should not be configured to monitor it. In summary, we have a working "recipe" for using PFs that works under certain conditions. The reported bugs cover the "negative ground". The core functionality works, but with known issues and limitations. As such, we should consider removing these as a blocker contingent on appropriate documentation of the aforementioned issues.
verified on OSPD10 puddle 2016-10-06.1 its looks ok except the bugs that already opened and attached in this bug [depends on] . https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/testrun?id=OSP-10-SRIOV-PF https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/testrun?id=NFV%2D001
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://rhn.redhat.com/errata/RHEA-2016-2948.html