I. Problem description

The RAID card cannot be seen on the BMC web interface and cannot be recognized under the BMC log card_info.

II. Processing procedure

The BMC fails to identify the RAID card. Note The BMC fails to obtain information about the RAID card. For the RAID controller card, the BMC is obtained through the I2C channel. Therefore, the BMC and BIOS identify the RAID card through independent links. For a standard RAID controller card, the BMC is identified by the BDF number reported by the BIOS. Therefore, if the BMC cannot be identified, the PCIE link is faulty.

1. Check whether the RAID card is an original component. A compatibility test has not been performed on the non-original component, and therefore it cannot be supported.

2. If it is an original part, you need to check the link:

• RAID controller card;

• RAID card (including supercapacitor and TFM) + mainboard.

III. Solution

1. First remove the super capacitor and TFM card to check whether it can be identified (excluding the case of super capacitor or TFM card fault pulling the RAID card power supply), replace the super capacitor (including TFM card) if it can be identified, if there is no spare part of the super capacitor, replace the standard RAID card;

2. after removing the supercapacitor can not identify, try to reinsert the RAID card can identify, can identify the previous installation problem;

3. still can not be identified after inserting and removing, it is recommended to carry RAID card, IO module, motherboard for investigation, priority replacement of RAID card followed by IO module, and finally replace the motherboard (CPU caused by low probability, if the replacement of the motherboard still can not be solved (X86 models), then continue to replace the corresponding CPU (see product documentation).

IV. suggestions and summary

1. priority check whether the parts are original;

2. followed by the priority with spare parts check the link:

• RAID card (including supercapacitor) + motherboard;

• Standard RAID card: RAID card (including supercapacitor) +I/O module + Mainboard +CPU (low probability).

Note: The ultracapacitor and TFM are replaced together.

I. Problem description

What services in OpenStack usually run on controller nodes?

II. Related services

The following services usually run on the control node:

• Certification Service (Keystone)

• Mirroring service (Glance)

• Nova services such as Nova API, Nova Scheduler, and Nova DB

• Block and object storage services (Cinder, Swift)

• Ceilometer services

• MariaDB/MySQL and RabbitMQ services

• Network (Neutron) and network proxy management services

• Orchestration Services (Heat)

I. Answer questions

If the user name and password are correct, and the token is within the validity period, can it be created successfully?

Answer: No, this permission is determined by the service.

II. Operation steps

Step1: Users apply for creating VMS through Dashboard/CLl and apply for Keystone authorization in RESTAPI mode.

Step2:keystone requests authentication information through users and generates auth-token to return the corresponding authentication request.

Step3: The interface or command line sends a boot instance request (with auth-token) to nova-api through RESTfulAPl;

Step4: After nova-api accepts the request, it sends an authentication request to keystone to check whether the token is a valid user and token;

Step5:keystone verifies whether the token is valid, if yes, return the valid authentication and the corresponding role (Note: some operations need to have the role permission to operate);

Step6: After the authentication, nova-api communicates with the database;

Step7: Initialize the database record of the newly created virtual machine;

Step8:nova-api uses rpc.cal to ask nova-scheduler if there is a Host ID for creating the virtual machine.

Step9: The nova-scheduler process listens to the message queue and obtains the request from nova-api.

Step10: Nova-Scheduler queries the computing resources in the nova database and calculates the hosts that meet the requirements of VM creation by scheduling algorithm.

Step11: nova-scheduler updates the physical host information of the VM in the database for the host that meets the requirement of VM creation;

Step12:nova-scheduler sends a VM creation request message to nova-compute through rpc.cgst；

Step13:nova-compute obtains the VM creation request message from the corresponding message queue；

Step14:nova-compute requests VM messages from nova-conductor through rpc.cal；

Step15:nova-conductor obtains the nova-compute request message from the message queue；

Step16:nova-conductor queries VM information based on the message；

Step17:nova-conductor obtains VM information from the database；

Step18:nova-conductor sends VM information to the message queue；

Step19:nova-compute obtains the VM information from the corresponding message queue；

Step20:nova-compute obtains the authentication token through keystone RESTfullAPl and requests glance-api through HTTP to obtain the image required for creating the VM；

Step21:glance-api verifies the validity of the token with keystone and returns the verification result;

Step22: If the token verification passes,nova-compute obtains the VM image information (URL);

Step23:nova-compute obtains the token of authentication k through keystone RESTfullAPl, and requests neutron-server to obtain the network information required for creating the VM through HTTP;

Step24:neutron-server verifies the validity of the token with keystone and returns the verification result;

Step25: After the token verification is successful,nova-compute obtains the VM network information;

Step26:nova-compute obtains the token through keystone's RESTfulAPl and requests cinder-api through HTTP to obtain the persistent storage information required for creating the VM;

Step27:cinder-api verifies the validity of the token with keystone and returns the verification result;

Step28: After the token verification is successful,nova-compute obtains the persistent storage information of the VM;

Step29:nova-compute invokes the configured virtualization driver based on the instance information to create a VM.

III. Solution：

View the permission's profile:

[rootecontroller cinder]# cd /etc/openstack-dashboard/

policy.json in this configuration file can view and modify the operation permissions of the role bound to the user on the component. View the roles that the corresponding component has permission to operate.

[rootecontroller openstack-dashboard]# ls

cinder_policy:json glance_policy.json keystone_policy.json local_settings neutron_policy.json nova_policy.d nova_policy.json。