Stx-regression: vSwitch 1G Hugepage available size cannot be changed

[Paulina Flores]

Brief Description
-----------------
vSwitch 1G Hugepage available size cannot be changed during baremetal stx-regression

Severity
--------
Minor

Steps to Reproduce
------------------
1. Login to horizon
2. Lock controller and change hugepages value for vSwitch
3. Create Instance with a flavor with a set mem_page_size that utilizes hugepages

Expected Behavior
------------------
Instance should be created with the hugepage value assigned on GUI.

Actual Behavior
----------------
Unable to change the vSwitch hugepage size to previously used 3000 in virtual environment after locking host, receiving an error about max 2M page value of 0 (shown in screenshot).

Reproducibility
---------------
The issue is 100% reproducible

System Configuration
--------------------
Duplex, MN-Local. (Tested in both)

Branch/Pull Time/Commit
-----------------------
bootimage.iso 21-Jun-2019 04:21
ISO: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190621T013000Z/outputs/iso/
Helm chart: stx-openstack-1.0-16-centos-stable-latest.tgz 21-Jun-2019 04:22

Last Pass
---------
I do not have Last pass information.

Timestamp/Logs
--------------
Attached screenshot of error message.

[Ghada Khalil (gkhalil)]

It appears that hugepage setting is not working properly in virtual env. This should be investigated/fixed, but not considered a high priority/gating item given it's not likely for this to be required in real life usec-ases.

[krishna pavan (ksamudrx)]

We have tested again with latest iso but still issue is persist.
Iso details:
SW_VERSION="19.01"
BUILD_ID="20190712T013000Z"
BUILD_NUMBER="178"
BUILD_DATE="2019-07-12 01:30:00 +0000"

[Oscar Medina Perez (omedinap)]

Issue was not seen on the latest ISO:

SW_VERSION="19.01"
BUILD_TARGET="Host Installer"
BUILD_TYPE="Formal"
BUILD_ID="20190802T013000Z"

JOB="STX_build_master_master"
<email address hidden>"
BUILD_NUMBER="200"
BUILD_HOST="starlingx_mirror"
BUILD_DATE="2019-08-02 01:30:00 +0000"

[Paulina Flores (paulina-flores)]

Hi. As Oscar mentioned, the error message no longer shows up on the GUI and we're able to change the hugepage values as expected, but there is a new behaviour observed: the VM instantiated fails to schedule. It also seems like the nova services cannot start.

I'm attaching the collected logs as well as the alarm list, the openstack compute service list, and the VM's fault message.

Alarm list:
[sysadmin@controller-0 ~(keystone_admin)]$ fm alarm-list
+-------+-------------------------------------+---------------------------------------+----------+-------------+
| Alarm | Reason Text | Entity ID | Severity | Time Stamp |
| ID | | | | |
+-------+-------------------------------------+---------------------------------------+----------+-------------+
| 700. | Instance vm owned by admin has | tenant= | critical | 2019-08-05T |
| 001 | failed to schedule | f19606e2-8279-4a66-8d2a-619431995728. | | 11:20:48. |
| | | instance=7cdcade6-f4c4-4fee-8d9d- | | 518022 |
| | | fec700b334ba | | |
| | | | | |
| 270. | Host controller-0 compute services | host=controller-0.services=compute | critical | 2019-08-05T |
| 001 | failure, failed to enable nova | | | 10:36:52. |
| | services | | | 112769 |
| | | | | |
| 100. | NTP configuration does not contain | host=controller-1.ntp | major | 2019-08-03T |
| 114 | any valid or reachable NTP servers. | | | 20:54:40. |
| | | | | 313834 |
| | | | | |
| 100. | NTP configuration does not contain | host=controller-0.ntp | major | 2019-08-03T |
| 114 | any valid or reachable NTP servers. | | | 20:17:28. |
| | | | | 267847 |
| | | | | |
+-------+-------------------------------------+---------------------------------------+----------+-------------+

Compute service list:
controller-0:$ openstack compute service list
+----+------------------+-----------------------------------+----------+---------+-------+----------------------------+
| ID | Binary | Host | Zone ...

[Paulina Flores (paulina-flores)]

Update on this: after upping the hugepage size for the host, the VM finally started correctly. Looks like it was a resource problem I was overlooking.

In that case, since the vm starts correctly and the memory used in the controller's node is reflected accordingly, I will be considering test as passed.

[zhao.shuai (zhao.shuai.neusoft)]

@Paulina Flores
Thanks for the update status, I don't know if this ticket can be closed.
If you have other questions, please re-create the LP ticket.
Thank you！

@Austin Sun
Then we will suspend the investigation this LP.
If you have any suggestions, please let us know.
Thank you！
From：<email address hidden>

[Austin Sun (sunausti)]

close it as issue is gone.