常见问题

一、 扩容计算节点主机名更新

• 问题描述：在扩容计算节点了计算节点之后，新添加的主机，在物理机中的hosts文件上不会立刻更新之后，容器不重启，不会更新，这导致，在热迁移指定节点，找不到目的主机
• 解决方法：重启计算节点上的nova_compute, nova_libvirt容器

  docker restart nova_compute nova_libvirt

三、raw 格式镜像转换、上传步骤

• 问题描述：一般的image格式为qcow2，因平台存储后端为ceph，因此建议上传到glance的镜像为raw格式。
• 转换步骤：

# 使用qemu-img工具转换
qemu-img convert win2012.qcow2 -O win2012.raw
# 确认转换是否成功：
qemu-img info win2012.raw

如图：

• 使用openstack命令上传到glance：

source /path/to/venv/bin/activate
source /etc/kolla/admin-openrc.sh
openstack image create --disk-format raw --container-format bare --public win2012 --file win2012.raw

四、 VIP同时存在于三个控制节点上

• 问题描述：VIP同时存在于三个控制节点上
• 解决办法：在部署节点使用ansible重启keepalived和haproxy服务解决，具体如下：

ansible -i /root/multinode control -m shell -a "docker restart keepalived"
ansible -i /root/multinode control -m shell -a "docker restart haproxy"

五、虚拟机创建失败，提示「No valid host was found」

• 问题描述
  通过 Dashboard/CLI 创建虚拟机时，报错No valid host was found，虚拟机处于ERROR状态，无实例 ID 或实例 ID 创建后无状态。
• 问题排查

1. 查看 Nova 调度器日志：tail -f /var/log/nova/nova-scheduler.log，过滤关键词No valid host/filter，确认是调度器过滤规则导致无符合条件的计算节点；
2. 检查计算节点状态：openstack compute service list，确认 nova-compute 服务是否为up状态，无down/disabled；
3. 验证计算节点资源：在控制节点执行nova hypervisor-show <计算节点名>，检查 CPU、内存、磁盘是否满足虚拟机创建要求（无资源不足）；
4. 检查虚拟机规格与计算节点属性：确认创建的虚拟机规格（flavor）的 CPU / 内存 / 磁盘未超过计算节点可用资源，且 flavor 无自定义属性（如 GPU、磁盘类型）与计算节点不匹配；

• 处理方法

1. 若计算节点 nova-compute 服务 down：在计算节点重启服务，并检查nova.conf中[keystone_authtoken]/[rabbitmq]配置是否正确；
2. 若计算节点资源不足：扩容计算节点资源，或调整虚拟机 flavor 规格，或启用 Nova 资源超配（在nova.conf中配置cpu_allocation_ratio/ram_allocation_ratio）；
3. 若调度器过滤规则导致：临时禁用不必要的过滤器（在nova.conf的[filter_scheduler]段修改enabled_filters），或修正计算节点属性使其符合过滤规则；

六、创建虚拟机失败

• 问题描述：虚拟机创建失败，涉及模块 nova-compute、nova-conductor、openvswitch-agent，影响云平台功能。
• 排查过程

1. 命令行查看nova/ovs 服务异常；
2. nova、neutron等组件日志显示 rabbitmq 连接断开且未重连，服务假死；

• 处理方法：重启相关容器后，日志正常输出，服务恢复。：docker stop/start nova_compute、nova_conductor、neutron_openvswitch_agent；

七、rabbitmq 脑裂

• 问题描述：rabbitmq 集群脑裂，control01、03 节点脱离集群但容器 UP。
• 排查过程

1. 检查集群状态发现节点脱离；
2. 查看 control02 日志，与另外两节点心跳停止，Mnesia 判定网络分区。

• 处理方法：重启 rabbitmq 服务：rabbitmqctl stop_app && rabbitmqctl start_app（control01、03 节点容器内执行）；

八、虚拟机 resize 失败

• 问题描述：虚拟机扩容失败，多次尝试扩容、迁移、疏散均未成功，涉及模块 Nova，影响云平台功能。
• 排查过程

1. 查看 migration 记录，虚拟机扩容时出现 error；
2. nova 日志提示 vcpu 超最大限制，初步怀疑资源不足；
3. 核查 com03 节点资源（88C/128C），排除资源不足；
4. 发现新 flavor 含 hw:live_resize 属性，该属性限制 vcpu 为物理 CPU 一半；单节点超配后 CPU 为 64C，flavor 超出限制导致失败。

• 处理方法：
  移除 live_resize 参数：openstack flavor unset --property hw:live_resize $flavorid；
  创建 flavor 时默认移除该属性，通过openstack flavor list/show $flavorid核查。

九、数据库脑裂

• 问题描述：控制节点数据库脑裂，导致云服务异常
• 处理方法：

1. 修复前检查，先查看各个控制节点是否有 safe_to_bootstrap =1，执行：

   ansible -i ~/multinode control -m shell -a 'cat /var/lib/docker/volumes/mariadb/_data/grastate.dat|grep safe_to_bootstrap'

2. 如果有节点值为1，直接写入下面mariadb_recover_inventory_name处，然后执行修复命令
3. 如果没有 查看ansible -i ~/multinode control -m shell -a 'cat /var/lib/docker/volumes/mariadb/_data/gvwstate.dat’
   有输出的，手动去修改safe_to_bootstrap值为1，再修复
4. 执行修复

   ansible -i multinode control -m shell -a 'docker stop mariadb'
   kolla-ansible -I /multinode  mariadb_recovery -e mariadb_recover_inventory_name=node33 |tee mariadb_recovery.log

十、虚拟机数据库中记录与libvirt底层记录不一致

• 问题描述：虚拟机数据库中记录与libvirt底层记录不一致；此现象源于虚拟机疏散和迁移，并且虚拟机状态error
• 处理方法：

1. 确认vm 在数据库中的记录
   openstack server show $vm_uuid |grep -Ei '(com|instance)'可以得出VM数据库中的记录及kvm底层信息
2. 在数据库记录的宿主机（A节点）查看该实例

   docker exec nova_libvirt virsh list --all |grep instance-xxx

3. B节点确认方法
   若为热迁移造成，则B节点为目标节点；若为疏散造成，可在数据库中确认B节点
4. 在B节点底层查看

   docker exec nova_libvirt virsh list --all |grep instance-xxx

5. B节点关闭虚拟机（B计算节点操作，该步骤是软关机虚拟机;destroy为硬关机虚拟机）

   virsh shutdown instance-xxx

6. 硬重启虚拟机

   nova reboot --hard  $vm_uuid

7. 在A节点底层查看实例是否成功运行

   docker exec -it -uroot nova_libvirt bash
   # 查看是否已经正常启动(若进入登录界面，则为正常启动状态)
   virsh console instance-xxx
   # 确认运行状态
   virsh list --all|grep instance-xxx

   8、确认A节点底层运行成功后，在B节点底层执行undefine操作

   # docker exec -itu root nova_libvirt bash
   # virsh undefine instance-xxx （B计算节点操作）

   9、、确认instance-xxx 是否在B节点undefine成功（B计算节点操作）

   virsh list --all|grep instance-xxx