文档中心知识库安全API Explorer
文档中心›KB›ZStack Cloud 云主机状态异常排查KB
文档目录

问题说明

提供 ZStack Cloud 云主机状态异常问题的结构化排查流程，重点覆盖 UI 显示 Unknown、Crashed、启动/停止/删除失败、平台状态与物理机底层状态不一致等场景。此类问题处理时必须优先防止脑裂，不能在未确认云主机实际运行位置前直接强制停止或修改状态。

现象

  • 云平台 UI 显示云主机状态为“未知”或状态长时间不变化。
  • 物理机失联或宕机后，云主机处于 Unknown 状态。
  • 云主机停用、启动、删除失败，或 CLI 修改状态失败。
  • 底层 virsh list --all 显示云主机为 crashed。
  • 部分云主机业务正常，部分云主机不可用，平台状态无法准确反映实际运行状态。

适用环境

  • 产品：ZCF
  • 组件：Cloud
  • 涉及对象：ZStack Cloud；云主机、物理机、KVM/libvirt、HA、共享存储、本地存储
  • 版本：4.x-4.8.38
  • 部署形态：单节点、多节点、共享存储、物理机失联或宕机场景

可能原因

该现象可能由以下一种或多种原因导致：

  • 物理机失联或宕机：平台无法确认失联物理机上的云主机是否仍在运行，为防止脑裂保持 Unknown。
  • 云主机未配置高可用：共享存储场景中，物理机失联后未开启 NeverStop 或高可用策略不满足，云主机不会自动恢复。
  • 底层 libvirt 状态异常：云主机在底层显示 crashed、shut off 或残留进程，平台状态未同步。
  • 存储或网络异常：主存储失联、物理机网络异常、存储锁或主机锁未释放，导致启动或状态修改失败。
  • 物理机硬件或系统故障：CPU/内存错误、内核异常、物理机假死或重启，导致其上云主机状态异常。
  • 控制面或任务异常：创建、删除、启动等任务卡住，导致状态长时间处于中间态。

排查步骤

按顺序执行以下检查。每一步都应确认当前状态是否符合预期，或指出下一步处理动作。

1. 确认状态异常的类型和范围

  • 检查项：确认是单台云主机异常，还是某台物理机上的所有云主机异常。
  • 命令/UI 路径：
  • 云平台查看云主机状态、所属物理机、最近任务、告警和 HA 策略。
  • 记录云主机 UUID、物理机 UUID、主存储 UUID 和异常时间窗口。
  • 预期结果：明确异常状态、影响范围、关联物理机和是否伴随物理机/主存储失联。
  • 异常处理：
  • 单台云主机异常优先检查底层 libvirt 状态和该云主机任务。
  • 某台物理机上全部云主机 Unknown，优先排查物理机失联、宕机、网络和硬件。

2. 优先确认是否存在脑裂风险

  • 检查项：确认云主机是否可能仍在某台物理机上运行。
  • 命令/UI 路径：
virsh list --all | grep <vmUuid>
ps -ef | grep <vmUuid>

可在相关物理机上逐台确认；如涉及多台物理机，应按资源位置和迁移/HA 记录缩小范围。

  • 预期结果：确认云主机实际运行状态和所在物理机。
  • 异常处理：
  • 未确认云主机不在任何物理机运行前，请勿直接执行强制停止、修改状态或指定其他物理机启动。
  • 如果发现同一云主机在多台物理机运行，应按脑裂高风险事件处理，先保护业务和数据。

3. 检查物理机状态和 HA 策略

  • 检查项：确认物理机是否失联、宕机、假死或已经恢复；确认云主机 HA 策略。
  • 命令/UI 路径：
  • 云平台查看物理机状态和 HA 策略。
  • 管理节点查看物理机相关告警和状态切换日志。
  • 物理机侧检查系统启动时间、硬件日志和系统日志。
  • 预期结果：物理机正常连接，或可解释云主机 Unknown 的物理机失联/宕机事件。
  • 异常处理：
  • 共享存储场景下，未配置高可用的云主机在物理机失联后可能保持 Unknown。
  • 若确认原物理机宕机且云主机未运行，可在授权后按流程修改状态为 Stopped，再指定其他物理机启动。
  • 若希望后续自动恢复，应评估设置云主机高可用策略为 NeverStop。

4. 检查底层 libvirt 状态

  • 检查项：确认底层 virsh 状态是否与 UI 状态一致。
  • 命令/UI 路径：
virsh list --all | grep <vmUuid>
virsh domstate <vmUuid>
  • 预期结果：底层状态与平台状态一致，或能解释平台状态异常。
  • 异常处理：
  • 如果底层为 crashed，平台侧停用/启动失败，需要获取用户授权后再评估 virsh destroy <vmUuid> 等强制动作。
  • 如果底层已经停止但平台仍 Unknown，可在确认无脑裂风险后通过 CLI 修正状态。
  • 强制操作前必须保留日志、确认业务影响并获得授权。

5. 检查启动、停止、删除或状态修改失败原因

  • 检查项：根据失败任务 UUID/API UUID 查看管理节点和 KVM agent 日志。
  • 命令/UI 路径：
grep -a -n "<apiUuid-or-taskUuid-or-vmUuid>" /usr/local/zstack/apache-tomcat/logs/management-server.log*
grep -a -n "<apiUuid-or-taskUuid-or-vmUuid>" /var/log/zstack/zstack-kvmagent.log*
  • 预期结果：能定位任务失败原因，例如锁未释放、主存储不可达、物理机不可用、libvirt 异常或权限不足。
  • 异常处理：
  • 如果报锁相关错误，先确认云主机是否仍在其他物理机运行，以及是否有未完成任务。
  • 如果删除失败，检查主存储状态、卷状态和底层卷是否存在。
  • 如果启动失败，先排查主存储、物理机资源、网络和底层 libvirt 状态。

6. 处理 Unknown 状态前的安全决策

  • 检查项：确认是否具备修改状态或恢复启动的条件。
  • 命令/UI 路径：
  • 云平台确认云主机原始物理机、主存储、HA 策略和业务影响。
  • 底层确认云主机没有运行进程。
  • 预期结果：可证明云主机不会因状态修改或重新启动造成脑裂。
  • 异常处理：
  • 底层确认已停止后，可在授权后使用 CLI 将状态调整为 Stopped。
  • 状态调整后再通过 UI 或 CLI 启动云主机，并验证系统和业务。
  • 不能确认底层状态时，应先恢复物理机连接或收集更多证据。

7. 收集支持信息

  • 云主机信息：UUID、名称、状态、HA 策略、所属物理机、主存储、最近任务。
  • 物理机信息：连接状态、是否宕机/重启、系统启动时间、硬件事件、资源负载。
  • 管理节点日志：/usr/local/zstack/apache-tomcat/logs/management-server.log*
  • 计算节点日志：/var/log/zstack/zstack-kvmagent.log*
  • 底层状态：virsh list --all、virsh domstate、qemu 进程、相关 qemu 日志。
  • 业务确认：云主机业务是否仍可访问，是否允许停机、强制停止或状态修正。

补充排查方法

基础排查命令

# 管理节点服务和集群基础状态
zstack-ctl status
systemctl status zstack-ha.service 2>/dev/null || true
systemctl status mariadb.service mysqld.service 2>/dev/null || true
zsha2 status 2>/dev/null || true

# 管理节点主日志和近期错误
ls -lh /usr/local/zstack/apache-tomcat/logs/management-server.log*
grep -iE 'ERROR|WARN|Exception|failed|timeout' /usr/local/zstack/apache-tomcat/logs/management-server.log | tail -n 200

# 基础资源与系统状态
df -hT
free -m
top -b -n 1 | head -n 30
journalctl -p warning --since '2 hours ago' --no-pager | tail -n 200

临时解决方案

  • 先区分管理面显示异常、资源状态异常和底层业务异常；只在确认底层状态正常时，才考虑重连、刷新缓存、重试任务或重启管理服务。
  • 如需重启管理节点服务，先确认 HA 状态、当前任务和业务窗口，优先单节点逐台处理，并保留 /usr/local/zstack/apache-tomcat/logs/management-server.log*。
  • 涉及数据库修复、资源强制删除、主存储/镜像服务器重连等操作时，先完成数据库备份并记录回退方案。

云主机与计算节点专项检查

zstack-cli QueryVmInstance uuid=<vm-uuid>
zstack-cli QueryHost uuid=<host-uuid>
zstack-cli QueryVolume vmInstanceUuid=<vm-uuid>
virsh list --all
virsh domstate <vm-name-or-id>
virsh dumpxml <vm-name-or-id> > /tmp/vm.xml
systemctl status libvirtd zstack-kvmagent 2>/dev/null || true
grep -iE 'ERROR|Exception|failed|timeout|qmp|libvirt|domain' /var/log/zstack/zstack-kvmagent.log | tail -n 200
grep -iE '<vm-uuid>|<vm-name>' /usr/local/zstack/apache-tomcat/logs/management-server.log | tail -n 200

云主机类临时处理建议

  • 云主机状态异常时先比对管理面、libvirt、QEMU 进程和业务侧状态，避免只根据 UI 状态执行停止或删除。
  • 控制台黑屏优先检查 VNC/SPICE 端口、代理、浏览器、物理机 agent 和虚拟机显卡配置；业务正常时可先规避为 SSH/RDP 登录。
  • 启动失败或异常关机应先保护 XML、agent 日志和管理日志；必要时先迁移/重连/刷新状态，强制操作需确认磁盘和快照链完整。

补充信息

  • 排查结论需结合当前版本、服务状态、日志、集群健康、近期变更和现场影响面确认。
  • 涉及数据库修改、强制删除、OSD/MON 重建、Pool 删除、服务重启或网络变更等高风险操作时，应先完成备份、审批和技术支持确认。
上一篇ZStack Cloud ZStone UI 无法登录与页面异常排查
ZStack Cloud 云主机状态异常排查 | 故障排查 · KB | ZStack 资源中心