当前位置：首页 > news >正文

openstack出错记录

news 来源：原创 2024/5/3 22:35:38

为什么80%的码农都做不了架构师？>>>

控制节点：

查看云主机: nova list

详细查看单个云主机: nova show [name]

查看各个节点状态：nova-manage service list

计算节点:

查看节点状态: service openstack-nova-compute status

重启节点: service openstack-nova-compute restart

虚拟机建立不起来的时候，有可能是，计算节点上的openstack服务down掉了，在控制节点上重启openstack服务即可。

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

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

虚拟机删掉了，但是volume还显示in-use状态，需要从数据库里面重置volume的状态。

[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";

有时候碰到硬盘太大，比如需要创建80G的虚拟机，则会创建失败，需要修改nova里面的vif超时参数。

vif_plugging_timeout=10

vif_plugging_is_fatal=False

在运行“/etc/init.d/network restart”命令时，出现错误“Job for network.service failed. See 'systemctl status network.service' and 'journalctl -xn' for deta”，运行“cat /var/log/messages | grep network”命令查看日志中出现的与network相关的信息

我出现的错误，是由于外网的物理地址与eth0不一样。后来将pub网指向eth0即可

7.14.2016

问题1：

控制节点与计算节点之间的时间不同步：

nova-manage service list检测服务状态原理：

最近更新时间，或者第一次创建时间与当前时间间隔少于CONF.service_down_time（60秒），则认为服务alive

从这里也可以得知为什么控制节点和计算节点的时间要一致。

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

问题 2：

Nova scheduler :Host has more disk space than database expected

原理：

宿主机 RAM 和 DISK 的使用率往往要小于虚拟机理论使用的 RAM 和 DISK，在剩余资源充足的条件下，libvirt 将成功创建虚拟机。

随想：内存和磁盘超配虽然能提供更多数量的虚拟机，当该宿主机上大量虚拟机的负载都很高时，轻着影响虚拟机性能，重则引起 qemu-kvm 相关进程被杀，即虚拟机被关机。因此对于线上稳定性要求高的业务，建议不要超配 RAM 和 DISK，但可适当超配 CPU。建议这几个参数设置为：

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

问题 3：

在nova-all.log日志中发现MessagingTimeout: Timed out waiting for a reply to message ID问题

日志中时不时出现”MessagingTimeout: Timed out waiting for a reply to message“，来点绝的，直接修改nova.conf文件，添加：

[conductor]
use_local=true

如果计算节点宕机了，但没有在nova里将这个host disable掉，在 service_down_time and report_interval setting时间内nova-schedule会误认为这个host仍然是alive的，从而出问题了。另外也可能是olso的bug, https://bugs.launchpad.net/oslo.messaging/+bug/1338732

或者去掉RetryFilter,

scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,Image

在neutron openswitch-agent .log 中发现

MessagingTimeout: Timed out waiting for a reply to message ID

neutron在同步路由信息时，会从neutron-server获取所有router的信息，这个过程会比较长（130s左右，和网络资源的多少有关系），而在/etc/neutron/neutron.conf中会有一个配置项“rpc_response_timeout”，它用来配置RPC的超时时间，默认为60s,所以导致超时异常.解决方法为设置rpc_response_timeout=180.