Bug 1402584
| Summary: | [RFE][nova]: Trusted Virtual Functions | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Stephen Gordon <sgordon> | |
| Component: | openstack-nova | Assignee: | Stephen Finucane <stephenfin> | |
| Status: | CLOSED ERRATA | QA Contact: | awaugama | |
| Severity: | urgent | Docs Contact: | ||
| Priority: | high | |||
| Version: | 8.0 (Liberty) | CC: | atelang, awaugama, berrange, brault, dasmith, djuran, ealcaniz, eglynn, fbaudin, jamsmith, jhakimra, jniu, kchamart, lmiccini, lyarwood, nyechiel, sbauza, sgordon, srevivo, stephenfin, vromanso, weiyongjun | |
| Target Milestone: | Upstream M2 | Keywords: | FutureFeature, Triaged | |
| Target Release: | 14.0 (Rocky) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| URL: | https://blueprints.launchpad.net/nova/+spec/sriov-trusted-vfs | |||
| Whiteboard: | upstream_milestone_none upstream_definition_drafting upstream_status_unknown | |||
| Fixed In Version: | openstack-nova-18.0.0-0.20180710150340.8469fa7 | Doc Type: | Enhancement | |
| Doc Text: |
With this update, the libvirt compute driver now allows users to create instances with trusted SR-IOV virtual functions. When trusted, a VF can perform certain operations, such as modifying the VF’s MAC address in the guest.
Interface bonding requires that all slaves use the same MAC address, which in turn requires MAC address modifications on one of the VFs during a failover. Because MAC address altering is a privileged operation, participating VFs must be trusted in order to successfully configure bonding in the guest.
Administrators can now configure trusted mode for VFs. This requires two steps. First, the 'trusted' value of the '[pci] passthrough_whitelist' JSON configuration option in nova.conf must be set to 'true'. For example:
[pci]
passthrough_whitelist = {"devname": "eth0", "trusted": "true",
"physical_network":"sriovnet1"}
Then, when creating the port, 'trusted=true' must be set for the binding profile. For example:
$ neutron port-create <net-id> \
--name sriov_port \
--vnic-type direct \
--binding:profile type=dict trusted=true
Because trusted mode only applies to SR-IOV VFs, the 'vnic-type' must be one of 'hw_veb' or 'direct'.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1656073 (view as bug list) | Environment: | ||
| Last Closed: | 2019-01-11 11:47:00 UTC | Type: | --- | |
| 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: | 1379787, 1384439 | |||
| Bug Blocks: | 1382052, 1442136, 1476900, 1500557, 1615667, 1636395, 1656071, 1656073, 1687560, 1732816 | |||
|
Description
Stephen Gordon
2016-12-07 21:44:40 UTC
Nir can we get a lucky volunteer from the networking team to take a look over the current iteration of the spec (we intend to re-submit for Pike): https://review.openstack.org/#/c/397932/ Vladik is interested in feedback on whether this will make sense from a Neutron POV. Upstream patches: https://review.openstack.org/#/q/topic:bp/sriov-trusted-vfs New spec proposed for Queens Spec re-proposed for Rocky: https://review.openstack.org/#/c/485522/ Patches merged upstream https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/sriov-trusted-vfs For the tests you need to configure pci/passtrhough_whitelist with trusted=true
[pci]
passthrough_whitelist = {"devname": "eth0", "trusted": "true",
"physical_network": "phys0"}
Then you need to create a port that is asking for a trusted VF device:
neutron port-create <net-id> --name sriov_port --vnic-type direct
--binding:profile type=dict trusted=true
Finally starting the instance using the port created.
The guest should start successfully and the vf assigned should indicate that trusted mode is active. using "ip link show eth" on host.
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/RHEA-2019:0045 |