一. 虚拟机停电后不能自动重启

现象： 一些虚拟机挂载了cinder的存储，cinder的存储在windows系统或者linux系统中实现了自动挂载。而不能自动启动，出现不能找到存储的情况

openstack版本newton

处理过程：
1  使不能自动重启的机器处于active状态
nova reset-state --active  XXXX
2 从界面或者命令把挂载的存储卸载
3 应重启虚拟机（虚拟机不能自动重启），进入维护的shell模式，关机
4 从界面或者命令重新挂载卸载的存储
5 再次硬启动虚拟机
故障分析：
不使用外接存储的虚拟机能够正常启动。使用外接存储的虚拟机不能正常启动。造成此种现象的原因如下：
外接存储和虚拟机使用的一台机器，虚拟机在启动的时候外接存储还没有完全处于正常状态，造成不能造成正常挂载存储，影响了虚拟机的正常启动。
处理方法： 重新挂载存储即可。

二  修改ubuntu时区

命令： timedatectl statis  查看时间状态 

timedatectl set-timezone "Asia/Shanghai" 就可以将时区设为上海时区。

三：如果虚拟机出现如下的错误“domain 'instance-0000000a' already exists with uuid 5f81a7d2-1b0f-8c72-4e1e-377c275e9289”如何处理？
1. 恢复虚拟机的状态
nova reset-state --active dev_backup_managment
2. 查看虚拟机
在虚拟机所在的主机
virsh list  查看active状态的。
virsh list --all   查看 see all domains.
in case virsh list --all is empty but the problem persists you may want to try restarting the service： service libvirtd restar
3. 进行处理：
Not yet familiar with OpenStack, but in regular old libvirt, that error usually implies not that there's a RUNNING instance, but that there's a DEFINED instance. "virsh list" only shows currently active VM's, not every defined VM. Try:

virsh edit instance-0000000a

If that pops open vim and has a bunch of XML in there, there's already a defined 'instance-0000000a' VM. If you are 100% sure you don't want it, quit out of the editor and use:

virsh undefine instance-0000000a

And then have OpenStack try whatever you were doing again, and it should work.

By the way, if you DO want what's there, you can start it with:

virsh start instance-0000000a
我是用这virsh undefine instance-0000000后再次硬重启虚拟机后成功。

四。重新定义虚拟机大小的时候，虚拟机可能发生迁移，如何保障虚拟机在同一台机器上？

修改controller和各个computer节点的nova.cnf文件，打开下面两个参数
allow_resize_to_same_host=True
scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

重启服务

systemctl restart openstack-nova-api.service
systemctl restart openstack-nova-consoleauth.service
systemctl restart openstack-nova-scheduler.service
systemctl restart openstack-nova-conductor.service
systemctl restart openstack-nova-novncproxy.service
systemctl restart openstack-nova-compute.service

经过测试，重新调整虚拟机大小的时候，只能从小往大调整。如果从大往小调整，比如内存，回重新错误。

 

五 Nova相关的服务状态为down的几种情况（此次遇见的是时间不同步）

当Openstack不正常工作时，首先查看下服务状态，比如执行nova service-list命令查看Nova相关的服务状态。如果服务状态为down，根据Openstack服务的心跳机制和状态监控原理，可能有以下几种故障情形：

1. 数据库访问错误导致心跳更新失败，这种情况看日志就能发现错误日志。

    mysql  -p -u root

2. Rabbitmq连接失败，nova-compute不能直接访问数据库，更新时是通过RPC调用nova-conductor完成的，如果rabbitmq连接失败，RPC将无法执行，导致心跳发送失败。
3. nova-conductor故障，原因同上，不过这种情况概率很低，除非人为关闭了该服务。
4. 时间不同步。这种情况排查非常困难，因为你在日志中是发现不了任何错误信息的，我们知道数据库操作由nova-conductor组件完成的，而计算心跳间隔是在nova-api服务完成的，假如这两个服务所在的主机时间不同步，将可能导致服务误判为down。对于多API节点部署时尤其容易出现这种情况，所有节点务必保证时间同步，NTP服务必须能够正常工作，否则将影响Openstack服务的心跳机制和状态监控。

此次搬家后，发现controller03节点计算服务不正常，出现down的情况，重启服务，重启机器，排查日志都没有找到原因。后从网上查阅：如果时间不同步，也可能出现上述现象。查controller03，发现时间不同步，配置了/etc/ chrony.conf,发现同步controller01 不能同步，重新配置了一个时间服务，此时间服务时通过/etc/ntp.conf 配置，时间同步后，计算节点正常了 。