Bug 1463838
| Summary: | [RFE] Guaranteed minimum bandwidth | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | JP Jung <jjung> | |
| Component: | openstack-nova | Assignee: | smooney | |
| Status: | CLOSED ERRATA | QA Contact: | James Parker <jparker> | |
| Severity: | urgent | Docs Contact: | ||
| Priority: | urgent | |||
| Version: | 13.0 (Queens) | CC: | akarlsso, amodi, antonio.lopezgracia, asimonel, brault, ccopello, dasmith, djuran, eelena, egallen, eglynn, fbaudin, fiezzi, gregraka, igallagh, jhakimra, kchamart, lyarwood, mbooth, nlevinki, nwolf, sbauza, sgordon, srevivo, stephenfin, vromanso, weiyongjun, yrachman | |
| Target Milestone: | Upstream M2 | Keywords: | FutureFeature, Triaged | |
| Target Release: | 16.0 (Train on RHEL 8.1) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | openstack-nova-20.0.1-0.20191025043858.390db63.el8ost | Doc Type: | Technology Preview | |
| Doc Text: |
In Red Hat OpenStack Platform 16.0, it is now possible to specify QoS minimum bandwidth rules when creating network interfaces. This feature ensures that the instance is guaranteed a specified portion of a network's available bandwidth. Currently, the only supported operations are resize and cold migrate.
For guidance on creating a guaranteed minimum bandwidth QoS policy, see https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/networking_guide/sec-qos#guaranteed-min-bw. Note that some of the configuration requires directly editing OpenStack Networking (neutron) initialization files, as heat parameters are not yet available.
For guidance on creating an instance that requests a guaranteed minimum bandwidth, see https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/instances_and_images_guide/ch-manage_instances#section-guaranteed-min-bw
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1634058 1780733 (view as bug list) | Environment: | ||
| Last Closed: | 2020-02-06 14:37:21 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, 1281573, 1991746, 1416067, 1419948, 1419954, 1476902, 1624465, 1634058, 1669584, 1769723, 1780733 | |||
I think we still need a deeper discussion on this, unfortunately not anything happening from a Compute POV for Queens/RHOSP 13. This is part of RHOSP14 QoS EPIC, that will be internally available before the end of the calendar year. *** Bug 1396265 has been marked as a duplicate of this bug. *** 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-2020:0283 |
Description of problem: * Some VNF requires the use of SRIOV for dataplane interfaces, specifying also a BW for that interface. The BW required for each interface is a requirement specified in the VNF descriptor. * PCI SRIOV allows multiplexing a single physical interface into several virtual interfaces called Virtual Functions (VF) or SRIOV interfaces. This means that from a single 10G physical interface we should be able to split it in several virtual functions each one consuming a different BW: * Example 1: 4 virtual functions with 5Gbps, 2Gbps, 2Gbps and 1Gbps * Example 2: 10 virtual functions, each one with 1Gbps * The number of VF configured in a physical interface can be high, for instance 64, but the number of actually used VF in a physical interface depends on the actual BW reserved for each VF and the total BW of the physical interface. * When searching a host to deploy a VM, nova scheduler should take into account the amount of BW reserved by the previous VMs on each physical interface. Today, BW is not taken into consideration. * Moreover, BW occupied on each physical interface is an important driver for host selection. It might make sense for nova to have some policy that prefers deploying on a host whose physical interfaces have less available BW in order to make a better use of the network resources.