Skip to content

Commit acbbc3e

Browse files
Zuulopenstack-gerrit
authored andcommitted
Merge "Documentation for bandwidth support"
2 parents 0dfbcd7 + 47287f6 commit acbbc3e

File tree

6 files changed

+120
-0
lines changed

6 files changed

+120
-0
lines changed

api-guide/source/conf.py

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -286,4 +286,6 @@
286286

287287
openstack_projects = [
288288
'nova',
289+
'neutron',
290+
'placement',
289291
]

api-guide/source/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -86,6 +86,7 @@ Contents
8686
polling_changes
8787
request_and_response_formats
8888
down_cells
89+
port_with_resource_request
8990

9091
.. toctree::
9192
:hidden:
Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
=================================
2+
Using ports with resource request
3+
=================================
4+
5+
Starting from microversion 2.72 nova supports creating servers with neutron
6+
ports having resource request visible as a admin-only port attribute
7+
``resource_request``. For example a neutron port has resource request if it has
8+
a QoS minimum bandwidth rule attached. Deleting such servers or detaching such
9+
ports works since Stein version of nova without requiring any specific
10+
microversion.
11+
12+
However the following API operations are still not supported in nova:
13+
14+
* Creating servers with neutron networks having QoS minimum bandwidth rule is
15+
not supported. The user needs to pre-create the port in that neutron network
16+
and create the server with the pre-created port.
17+
18+
* Attaching Neutron ports and networks having QoS minimum bandwidth rule is not
19+
supported.
20+
21+
* Moving (resizing, migrating, live-migrating, evacuating, unshelving after
22+
shelve offload) servers with ports having resource request is not yet
23+
supported.
24+
25+
See :nova-doc:`the admin guide <admin/port_with_resource_request.html>` for
26+
administrative details.

doc/source/admin/adv-config.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -30,3 +30,4 @@ instance for these kind of workloads.
3030
huge-pages
3131
virtual-gpu
3232
file-backed-memory
33+
port_with_resource_request
Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
=================================
2+
Using ports with resource request
3+
=================================
4+
5+
Starting from microversion 2.72 nova supports creating servers with neutron
6+
ports having resource request visible as a admin-only port attribute
7+
``resource_request``. For example a neutron port has resource request if it has
8+
a QoS minimum bandwidth rule attached.
9+
10+
The :neutron-doc:`Quality of Service (QoS): Guaranteed Bandwidth <admin/config-qos-min-bw.html>`
11+
document describes how to configure neutron to use this feature.
12+
13+
Resource allocation
14+
~~~~~~~~~~~~~~~~~~~
15+
16+
Nova collects and combines the resource request from each port in a boot
17+
request and sends one allocation candidate request to placement during
18+
scheduling so placement will make sure that the resource request of the ports
19+
are fulfilled. At the end of the scheduling nova allocates one candidate in
20+
placement. Therefore the requested resources for each port from a single boot
21+
request will be allocated under the server's allocation in placement.
22+
23+
24+
Resource Group policy
25+
~~~~~~~~~~~~~~~~~~~~~
26+
27+
Nova represents the resource request of each neutron port as a separate
28+
:placement-doc:`Granular Resource Request group <usage/provider-tree.html#granular-resource-requests>`
29+
when querying placement for allocation candidates. When a server create request
30+
includes more than one port with resource requests then more than one group
31+
will be used in the allocation candidate query. In this case placement requires
32+
to define the ``group_policy``. Today it is only possible via the
33+
``group_policy`` key of the :nova-doc:`flavor extra_spec <user/flavors.html>`.
34+
The possible values are ``isolate`` and ``none``.
35+
36+
When the policy is set to ``isolate`` then each request group and therefore the
37+
resource request of each neutron port will be fulfilled from separate resource
38+
providers. In case of neutron ports with ``vnic_type=direct`` or
39+
``vnic_type=macvtap`` this means that each port will use a virtual function
40+
from different physical functions.
41+
42+
When the policy is set to ``none`` then the resource request of the neutron
43+
ports can be fulfilled from overlapping resource providers. In case of neutron
44+
ports with ``vnic_type=direct`` or ``vnic_type=macvtap`` this means the ports
45+
may use virtual functions from the same physical function.
46+
47+
For neutron ports with ``vnic_type=normal`` the group policy defines the
48+
collocation policy on OVS bridge level so ``group_policy=none`` is a reasonable
49+
default value in this case.
50+
51+
If the ``group_policy`` is missing from the flavor then the server create
52+
request will fail with 'No valid host was found' and a warning describing the
53+
missing policy will be logged.
54+
55+
Virt driver support
56+
~~~~~~~~~~~~~~~~~~~
57+
58+
Supporting neutron ports with ``vnic_type=direct`` or ``vnic_type=macvtap``
59+
depends on the capability of the virt driver. For the supported virt drivers
60+
see the :nova-doc:`Support matrix <user/support-matrix.html#operation_port_with_resource_request>`
61+
62+
If the virt driver on the compute host does not support the needed capability
63+
then the PCI claim will fail on the host and re-schedule will be triggered. It
64+
is suggested not to configure bandwidth inventory in the neutron agents on
65+
these compute hosts to avoid unnecessary reschedule.

doc/source/user/support-matrix.ini

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1639,3 +1639,28 @@ driver.libvirt-vz-vm=missing
16391639
driver.libvirt-vz-ct=missing
16401640
driver.powervm=missing
16411641
driver.zvm=missing
1642+
1643+
[operation.port-with-resource-request]
1644+
title=SR-IOV ports with resource request
1645+
status=optional
1646+
notes=To support neutron SR-IOV ports (vnic_type=direct or vnic_type=macvtap)
1647+
with resource request the virt driver needs to include the 'parent_ifname'
1648+
key in each subdict which represents a VF under the 'pci_passthrough_devices'
1649+
key in the dict returned from the ComputeDriver.get_available_resource()
1650+
call.
1651+
cli=nova boot --nic port-id <neutron port with resource request> ...
1652+
driver.xenserver=missing
1653+
driver.libvirt-kvm-x86=complete
1654+
driver.libvirt-kvm-aarch64=missing
1655+
driver.libvirt-kvm-ppc64=missing
1656+
driver.libvirt-kvm-s390x=missing
1657+
driver.libvirt-qemu-x86=complete
1658+
driver.libvirt-lxc=missing
1659+
driver.libvirt-xen=missing
1660+
driver.vmware=missing
1661+
driver.hyperv=missing
1662+
driver.ironic=missing
1663+
driver.libvirt-vz-vm=missing
1664+
driver.libvirt-vz-ct=missing
1665+
driver.powervm=missing
1666+
driver.zvm=missing

0 commit comments

Comments
 (0)