问题说明

本文用于排查“更改主机后 UI 一直显示迁移中但底层无任务”。在完成证据检查前，不将该现象归因于单一产品缺陷。

现象

ZSphere 5.1.0 更改主机后，UI 长时间显示迁移中，但 domjobinfo 查不到迁移任务；重启管理节点也未清除状态，虚拟机 无法正常进入业务。

适用环境

• 产品：ZVF ZSphere
• 版本：5.1.0（已记录案例）
• 组件：ZSphere 更改主机、管理节点任务状态和 libvirt 虚拟机 状态
• 部署形态：执行“更改主机”后 UI 长期停留在迁移中，业务 虚拟机 无法进入

可能原因

• 当前只确认控制面与数据面状态不一致：UI 仍有迁移任务，但 libvirt domjobinfo 已无迁移任务。
• 重启管理节点未清除已记录案例中的任务状态，说明它不是单纯的管理节点进程内缓存。
• 由于恢复前缺少完整任务 UUID、日志和状态快照，迁移状态在哪一环节残留仍未知；本文不能据此认定产品缺陷或稳定复现条件。

排查步骤

1. 恢复前保存控制面任务证据

• 检查对象：虚拟机 UUID、迁移任务/API UUID、开始时间、UI 状态和管理节点日志。
• 操作位置：保存任务详情/API 返回，并在管理节点日志中按 虚拟机 UUID 和任务 UUID 导出完整迁移时间窗；同时记录业务是否仍可访问。
• 预期结果：能够确认迁移任务仍在真实执行，或明确它只剩控制面状态。
• 异常处理：如果任务 UUID 和时间窗缺失，先保留现有页面、API 和日志证据；不要先重启管理节点，因为已记录案例已证明重启不一定清除该状态，还会丢失进程级现场。

2. 在当前主机确认 libvirt 是否仍有迁移任务

• 检查对象：受影响虚拟机的 libvirt job 和运行状态。在平台记录的当前主机上执行：

  KB_VM_UUID='将受影响虚拟机 UUID 粘贴到这里'
  virsh domjobinfo "$KB_VM_UUID"
  virsh domstate "$KB_VM_UUID"

• 预期结果：UI 显示迁移中时，domjobinfo 应返回对应迁移 job；虚拟机 状态与平台一致。
• 异常处理：domjobinfo 明确无任务但 UI 仍显示迁移中时，保存完整输出和 libvirt 日志，进入控制面残留分支；若仍有 job，则继续按真实迁移任务排查，禁止执行后续强制恢复。

3. 确认是否满足现场强制恢复的全部前提

• 检查对象：libvirt 无迁移 job、业务不可进入、平台状态无法自行收敛以及应用方的数据风险接受。
• 操作位置：由 ZStack 技术支持和业务负责人共同确认：恢复前证据已保存、虚拟机 所在主机准确、没有迁移/块任务、应用可以接受强制断电造成的未落盘数据丢失，并具备应用侧恢复或数据校验方法。
• 预期结果：只有全部条件满足，才能使用已记录案例中的强制恢复；任一条件不满足都不执行。
• 异常处理：虚拟机 仍有 job、主机不确定或业务不能接受强制断电时，停止操作并继续由支持人员分析。

4. 支持协助执行强制停止、状态修正和启动

临时方案（Workaround）

• 支持协助方案：已记录案例按以下顺序恢复业务，但该方案会强制终止 虚拟机，不是通用自助操作。由支持人员在确认准确主机后执行 virsh destroy 虚拟机_UUID；随后使用准确版本的受支持方式把平台 虚拟机 状态修正为 Stopped，再从 UI 启动虚拟机。本文不提供直接修改数据库状态的命令。
• 预期结果：虚拟机 从 UI 正常启动，平台不再显示迁移中，virsh domstate 虚拟机_UUID 与平台状态一致，应用完成文件系统和业务数据校验。
• 异常处理：virsh destroy 失败、平台状态无法修正或 虚拟机 启动失败时立即停止；保留输出并由 ZStack 技术支持继续处理，禁止重复强制停止或直接改库。

补充信息

• 提交支持信息时，应包含准确时间窗、资源和任务 UUID、完整错误文本及相关组件日志。
• 不能从单个现场结果外推所有版本；根因未闭合或操作可能影响业务、数据时，应停止自助处理并提交本文列出的证据。