Large network throttle values cause instance launch failure
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Compute (nova) |
Triaged
|
Low
|
Unassigned | ||
Bug Description
Steps to reproduce
==================
Set network throttle properties of a flavor to something large, such as 40Gbps (specified in KiB per second):
quota:vif_
Launch an instance.
Easy to reproduce. Lowering the quota values to something smaller (15Gbps or less is what I have tested so far), works fine, so I'm guessing we're running into a 32-bit number issue (too large of throttle to store in a 32-bit number), or a signed number issue (negative number is being generated by setting the throttle too high and wrapping around.
Might be a limitation in LibVirt.
Expected result
===============
Successful instance launch.
Actual result
=============
Server status is ERROR. Fault information indicates:
build of instance XXXXX aborted. Volume attachment YYYYY could not be found.
where XXXXX and YYYYY are UUIDs.
Environment
===========
stable/rocky deployed with Kolla-Ansible 7.0.0.0rc2 with latest Kolla and Kolla-Ansible built from source.
All machines are running CentOS with the latest elrepo kernel (as of today): 4.18.12-
Hypervisor is KVM.
Storage is Ceph on SSDs.
Network is Neutron DVR (with OpenVSwitch).
Regarding version of nova - I'm not sure how to get this from the containers since rpm lists nothing from inside any of the Kolla Nova containers.
| Changed in nova: | |
| importance: | Undecided → Low |
| status: | New → Triaged |
| tags: | added: libvirt network neutron |
| Eric Miller (erickmiller) wrote | #2 |
| tags: |
added: doc removed: docs |
i am rather conflicted on how to triage this bug.
while still possible the use of the vif quotas e.g.
quota:vif_
is strongly discuraged in favour of neuton qos policies.
they are not supported by all hyperviors and the range of values may be hyperviour specific.
beyond the interop concerns these options also have no effect for ovs-dpdk vpp or other vhost-user based VIF and likely do not work for hardware offloaded ovs or directmode sriov.
with that in mind however we have not deprecated the bandwith io quotas as such they should still be supported to at least some degree.
i think we should really consider deprecateing the option in Stein and remove in the T release.
for now however we should also update the documention to refect the valid range and direct people to the neutron qos policies instead.