Shulou(Shulou.com)05/31 Report--

This article mainly introduces how to do openstack error, has certain reference value, interested friends can refer to, I hope you have a lot of gains after reading this article, let Xiaobian take you to understand.

Control node:

View Cloud Hosting: nova list

View individual cloud hosts in detail: nova show [name]

View node status: nova-manage service list

Compute node:

View node status: service openstack-nova-compute status

Restart node: service openstack-nova-compute restart

1.

When the virtual machine cannot be established, it is possible that the openstack service on the compute node is down. Restart the openstack service on the control node.

[root@controlNode01 network-scripts]# nova service-list

| 6 | nova-compute | computeNode01 | nova | enabled | down | 2016-02-26T06:47:45.000000 | None |

[root@controlNode01 network-scripts(keystone_ALUvRAN)]#openstack-service restart

2.

The virtual machine is deleted, but the volume still shows an in-use status. You need to reset the volume status from the database.

[root@controlNode01]# mysql cinder

MariaDB [cinder]> SELECT id,status,attach_status,mountpoint,instance_uuid from volumes;

MariaDB [cinder]> UPDATE volumes SET status="available", attach_status="detached", mountpoint=NULL, instance_uuid=NULL WHERE id="336d3e1c-298e-437d-a469-c2872cbe1a3a";

3.

Sometimes when the hard disk is too large, for example, if you need to create an 80G virtual machine, you will fail to create it. You need to modify the vif timeout parameter in nova.

vif_plugging_timeout=10

vif_plugging_is_fatal=False

4.

Error "Job for network.service failed." when running "/etc/init.d/network restart" command See 'systemctl status network.service' and 'journalctl -xn' for deta", run"cat /var/log/messages| grep network"command to view network-related information that appears in the log

My error is due to the physical address of the external network being different from eth0. Later, the pub net can be pointed to eth0

7.14.2016

Question 1:

Time synchronization between control nodes and compute nodes:

nova-management service list Principle of detecting service status:

service is considered alive if it was last updated, or if it was first created less than CONF.service_down_time (60 seconds) from the current time

Here you can also see why the control node and compute node time should be consistent.

http://blog.csdn.net/tantexian/article/details/39204993

Question 2:

Nova scheduler :Host has more disk space than database expected

Principle:

Host RAM and DISK usage tends to be less than virtual machine theoretical RAM and DISK usage, and libvirt will successfully create virtual machines provided sufficient resources remain.

Random thought: although memory and disk overallocation can provide a larger number of virtual machines, when the load of a large number of virtual machines on the host machine is very high, it will slightly affect the performance of the virtual machine, and seriously cause qemu-kvm related processes to be killed, that is, the virtual machine is shut down. Therefore, for the business with high online stability requirements, it is recommended not to over-configure RAM and DISK, but over-configure CPU appropriately. It is recommended that these parameters be set as:

CPU: CONF.cpu_allocation_ratio = 4

RAM: CONF.ram_allocation_ratio = 1.0

DISK: CONF.disk_allocation_ratio = 1.0

RAM-Reserve: CONF.reserved_host_memory_mb = 2048

DISK-Reserve: CONF.reserved_host_disk_mb = 20480

http://blog.csdn.net/wsfdl/article/details/45418727

Question 3:

MessagingTimeout: Timed out waiting for a reply to message ID problem found in nova-all.log log

"MessagingTimeout: Timed out waiting for a reply to message" appears from time to time in the log. To click absolutely, modify the nova.conf file directly and add:

[conductor]

use_local=true

If the compute node goes down but does not disable the host in nova, nova-schedule will mistake the host for alive during service_down_time and report_interval setting, and the problem will occur. It may also be a bug in olso, https://bugs.launchpad.net/oslo.messaging/+bug/1338732

or remove RetryFilter,

scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,Image

Found in neutron openswitch-agent.log

MessagingTimeout: Timed out waiting for a reply to message ID

When neutron synchronizes routing information, it will obtain all router information from neutron-server, which will take a long time (about 130s, depending on the number of network resources). In/etc/neutron/neutron.conf, there will be a configuration item "rpc_response_timeout", which is used to configure RPC timeout. The default is 60s, so it causes timeout exception. The workaround is to set rpc_response_timeout=180.

Delay is a big move to solve various problems...

Thank you for reading this article carefully. I hope the article "What to do with openstack error" shared by Xiaobian will help everyone. At the same time, I hope everyone will support you more, pay attention to the industry information channel, and more relevant knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.