Bug 1691040
| Summary: | [OSP15][RFE] Not able to attach more than 26 virtio-scsi volumes | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Lee Yarwood <lyarwood> | |
| Component: | openstack-nova | Assignee: | melanie witt <mwitt> | |
| Status: | CLOSED ERRATA | QA Contact: | James Parker <jparker> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 10.0 (Newton) | CC: | aguetta, amcleod, brault, cmuresan, dasmith, dhill, dwojewod, egallen, eglynn, fandrade, igallagh, jhakimra, jparker, kchamart, lyarwood, mbooth, mreinke, mschuppe, mwitt, nagata3333333, nova-maint, pcbho, pmannidi, sbauza, srevivo | |
| Target Milestone: | z2 | Keywords: | FutureFeature, Triaged, ZStream | |
| Target Release: | 15.0 (Stein) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | openstack-nova-19.0.0-0.20190322080331.c993d4f.el8ost | Doc Type: | If docs needed, set a value | |
| Doc Text: |
A new Compute (nova) parameter is now available, max_disk_devices_to_attach, which you can use to specify the maximum number of disk devices that can be attached to a single instance. The default is unlimited (-1). The following example illustrates how to change the value of max_disk_devices_to_attach to "30":
parameter_defaults:
ComputeExtraConfig:
nova::config::nova_config:
[compute]/max_disk_devices_to_attach:
value: '"30"'
|
Story Points: | --- | |
| Clone Of: | 1583553 | |||
| : | 1691041 (view as bug list) | Environment: | ||
| Last Closed: | 2020-03-05 11:54:29 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: | 1476902, 1583553, 1744079, 1771502, 1781791 | |||
| Bug Blocks: | 1635215, 1635220, 1691041, 1772124, 1772372, 1774604 | |||
|
Comment 3
Stephen Finucane
2019-05-09 14:12:38 UTC
Hi guys, we're wondering if there is any ETA in fixing this issue, also what's the expected version? Thanks, Cristian (In reply to Cristian Muresanu from comment #9) > Hi guys, > > we're wondering if there is any ETA in fixing this issue, also what's the > expected version? > > Thanks, > Cristian Hi, this feature is included in version openstack-nova-19.0.0-0.20190322080331.c993d4f.el8ost (as shown in the "Fixed In Version" in this rhbz). Are you asking about an ETA for QE verification, or something else? (In reply to melanie witt from comment #10) > (In reply to Cristian Muresanu from comment #9) > > Hi guys, > > > > we're wondering if there is any ETA in fixing this issue, also what's the > > expected version? > > > > Thanks, > > Cristian > > Hi, this feature is included in version > openstack-nova-19.0.0-0.20190322080331.c993d4f.el8ost (as shown in the > "Fixed In Version" in this rhbz). Are you asking about an ETA for QE > verification, or something else? Hi, I was looking to an errata. The actual version i my last ticket is RHOSP10. My understanding is the fix will be for RHOSP15, so my next question is a back-port solution is possible and to what OpenStack version? Thanks, (In reply to Cristian Muresanu from comment #11) > (In reply to melanie witt from comment #10) > > (In reply to Cristian Muresanu from comment #9) > > > Hi guys, > > > > > > we're wondering if there is any ETA in fixing this issue, also what's the > > > expected version? > > > > > > Thanks, > > > Cristian > > > > Hi, this feature is included in version > > openstack-nova-19.0.0-0.20190322080331.c993d4f.el8ost (as shown in the > > "Fixed In Version" in this rhbz). Are you asking about an ETA for QE > > verification, or something else? > > Hi, I was looking to an errata. The actual version i my last ticket is > RHOSP10. My understanding is the fix will be for RHOSP15, so my next > question is a back-port solution is possible and to what OpenStack version? Understood. Let me double check with the team on when we should expect the feature to appear in errata. The feature is being backported to OSP14 [1] and OSP13 [2] but will not go back further, as OSP10 is in maintenance support. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1691041 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1635215
There is a libvirt regression in RHEL 7.7 (and also affects RHEL 8.1):
https://bugzilla.redhat.com/show_bug.cgi?id=1741782
Cannot hotplug disk with address at unit=7
tl;dr: It used to be the case that the 'unit' 7 was reserved and
couldn't be used by QEMU, but that limitation no longer applies,
and must be removed by libvirt.
There's an upstream libvirt patch series to address it:
https://www.redhat.com/archives/libvir-list/2019-September/msg00407.html
If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field. The documentation team will review, edit, and approve the text. If this bug does not require doc text, please set the 'requires_doc_text' flag to '-'. 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/RHBA-2020:0711 |