文档中心知识库安全API Explorer
文档中心›KB›备份失败并显示 block jobs not found 或 only found MKB
文档目录

问题说明

本文用于排查多硬盘备份时 block jobs not found、expect N block jobs, only found M 等错误，并区分存储 I/O 抖动与持久性的硬盘路径不一致。

现象

  • zstore.log 或备份任务详情显示期望 N 个 block job，实际只找到 M 个。
  • 重试后部分任务成功，或同一时间段多个虚拟机同时失败。
  • 另一类任务始终报“在虚拟机上找不到卷 installPath”，重试无效。

适用环境

  • 产品：ZVF ZSphere
  • 版本：4.10.16（诊断分支与运行包的直接证据）
  • 组件：镜像存储（ImageStore）虚拟机备份、zstcli/zstack-store、KVM/libvirt block job
  • 部署形态：包含一块或多块待备份硬盘；本文分别覆盖“block job 数量短暂不一致”和“卷不在当前 domain XML”两类错误

可能原因

  1. 备份服务器底层 I/O 慢或网络/libvirt 状态抖动，3 秒轮询窗口内 block job 短暂不可见。
  2. 备份 job 并发或读写速度配置过高，放大状态不同步。
  3. 管理节点 VolumeVO.installPath 与当前 libvirt domain XML 不一致；这是持久性问题，不属于短暂 block job 缺失。

排查步骤

1. 先按错误文本分支

  1. 在 ZSphere UI 打开失败任务详情，记录 apiId、失败时间、虚拟机 UUID 和硬盘 UUID。SSH 登录管理节点，把实际 apiId 粘贴到变量中：
   KB_API_UUID='将任务详情中的apiId粘贴到这里'
   cd /usr/local/zstack/apache-tomcat/logs || exit 1
   ls -lh management-server.log*
   zgrep -a -n -C 3 "$KB_API_UUID" management-server.log*
   zgrep -a -n "$KB_API_UUID" management-server.log* | grep -E 'json POST|http response'

输出中的 json POST 是管理节点发出的请求，http response 是 Agent 返回。记录请求 URL、目标 IP、taskuuid/taskUuid 和完整响应；/vm/volume/takebackup 通常指向 虚拟机 所在 ZSphere 主机，/imagestore/exportnbdimage 通常指向 镜像存储（ImageStore）备份服务器。若查不到，先检查管理节点、UUID 和故障日期，再查对应 .gz 归档，不要仅凭任务页面的最后一句错误继续处理。

  1. SSH 登录上一步确定的镜像存储（ImageStore）备份服务器，用 taskuuid 同时查询当前和轮转的 zstore 日志：
   KB_TASK_UUID='将management-server日志中的taskuuid粘贴到这里'
   cd /var/log/zstack/zstack-store || exit 1
   ls -lh zstore*
   zgrep -a -n -C 5 "$KB_TASK_UUID" zstore*
   zgrep -a -n "$KB_TASK_UUID" zstore* | grep -iE 'block jobs|only found|not found|iohung|error|fail|timeout'
  1. SSH 登录上一步确定的 ZSphere 主机，使用发往该 ZSphere 主机请求行中的 taskuuid 查询 KVM Agent 日志；不要误用发往镜像存储（ImageStore） 的另一个 taskuuid：
   KB_TASK_UUID='将management-server日志中的taskuuid粘贴到这里'
   cd /var/log/zstack || exit 1
   ls -lh zstack-kvmagent.log*
   zgrep -a -n -C 5 "$KB_TASK_UUID" zstack-kvmagent.log*
  1. 在三端日志中记录完整错误、虚拟机 UUID、期望/实际 block job 数量和失败时间。需要上下翻看当前日志时使用 vim -R 日志文件，输入 / 后粘贴 UUID 并按 Enter，按 n 看下一处，输入 :q! 退出。
  • 如果错误为 expect N block jobs, only found M 或 block jobs not found，进入第 2 步。
  • 如果错误为 unable to find volume[installPath:...] on vm[...]，进入第 3 步；该错误表示备份请求中的硬盘路径没有匹配当前 domain XML，单纯等待 I/O 恢复通常无效。

2. 连续观察 block job 是否只是短暂不可见

  • 执行位置：受影响 虚拟机 当前所在的 ZSphere 主机。
  • 检查动作：在备份刚开始或错误复现时连续执行以下只读命令，并保留带时间戳的多次输出：
  KB_VM_UUID='将失败任务中的虚拟机 UUID 粘贴到这里'
  virsh qemu-monitor-command "$KB_VM_UUID" '{"execute":"query-block-jobs","arguments":{}}' --pretty
  • 预期结果：每块待备份磁盘都出现对应 block job，job 数量与错误中的 N 一致，且 offset 等进度字段持续变化。
  • 异常分支 A：某次查询为空、随后 job 出现并继续推进，按短暂可见性/I/O 抖动处理；同时检查 ZSphere 主机到备份服务器的网络和底层 NFS/multipath 延迟。
  • 异常分支 B：连续查询都少同一块盘，转第 3 步核对该盘是否仍挂载到 虚拟机。
  • 代码边界：当前审阅的 image-store/backup/backup.go 每约 3 秒查询一次，数量不一致会直接报错；这能解释错误形式，但不能证明所有现场都由存储慢导致。

3. 核对日志中的 installPath 与 虚拟机 当前 XML

  • 执行位置：虚拟机 当前所在 ZSphere 主机。
  KB_VM_UUID='将失败任务中的虚拟机 UUID 粘贴到这里'
  virsh dumpxml "$KB_VM_UUID" | grep -A2 '<source'
  • 预期结果：错误中记录的每个 installPath 都能在对应磁盘的 <source> 中找到，磁盘数量与备份请求一致。
  • 异常处理：如果某个路径始终不存在，记录缺失路径、硬盘 UUID 和完整 XML。由具备平台数据库只读权限的支持人员核对 VolumeVO.vmInstanceUuid、installPath、status 和 lastOpDate；不要直接改库或在未确认业务归属时 detach/attach 硬盘。

4. 核对执行包和日志采集位置

  • 虚拟机备份由 ZSphere 主机上的 /usr/local/zstack/imagestore/bin/zstcli 发起，诊断日志可能位于 /tmp/vmback/、/var/log/zstack/zstack-kvmagent.log 和 /var/log/zstack/zstcli/。
  • 镜像存储（ImageStore）主机侧同时收集 /var/log/zstack/zstack-store/zstore.log，管理节点收集 /usr/local/zstack/apache-tomcat/logs/management-server.log。
  • 如果 ZSphere 主机上的客户端没有预期诊断输出，先确认实际执行主机和运行包，不要只检查管理节点或 备份存储 主机上的包源。

5. 临时处置和验证

临时方案（Workaround）

  • 短暂缺失分支的适用条件：虚拟机 当前 XML 包含全部待备份磁盘，连续查询中缺失的 job 会重新出现，或 NFS/multipath 延迟与数量不一致处于同一时间窗。
  • 临时执行：先记录原备份计划和并发安排，暂停同一备份服务器上的批量计划；等待已有备份/恢复任务正常结束后，一次只对 1 台 虚拟机 发起相同备份，并同时保存 block-job、zstore 和存储延迟样本。不要通过 kill zstcli/QEMU 进程清空任务。
  • 分支处置：低并发成功时保留错峰、单 虚拟机 调度，先修复已确认的网络/NFS/multipath 延迟，再逐步恢复原并发；低并发仍缺少同一 job 时停止重试，转入路径不一致或特定硬盘失败分支。
  • 路径不一致分支：暂无经验证的通用自助方案。提交 虚拟机/硬盘 UUID、缺失 installPath、domain XML 和只读数据库核对结果，由 ZStack 技术支持恢复平台挂载关系后再备份。
  • 不要调整 ZS_MONITOR_INTERVAL；当前备份 block-job 调用路径不读取该变量。不要强制终止 block job 或重写 虚拟机/硬盘状态。
  • 验证成功的标准是同一虚拟机的所有磁盘都建立 block job、备份完成，且 zstore.log 不再出现数量不一致或硬盘路径缺失。
  • 回退：低并发仅改变调度，不修改平台参数。若验证失败，保留原计划配置但继续暂停其执行并升级支持；根因修复且单 虚拟机 验证通过后，再按记录恢复原计划和并发。

补充信息

  • 需固定版本化修复包时，同时提供 ZSphere 主机和 镜像存储（ImageStore）主机的实际运行二进制信息；不要只提供管理节点包源文件。
  • 各版本的 block-job 容忍窗口和修复状态并不统一；重试或调整并发前应先确认现场构建和连续采样结果。
上一篇添加 AD/LDAP 服务器时测试连接失败，并显示“Cannot connect to LDAP/AD server”下一篇删除分布式交换机后，宿主机 bond 被删除
备份失败并显示 block jobs not found 或 only found M | 故障排查 · KB | ZStack 资源中心