来源与分类

• 来源渠道：内部 Jira/TIC。
• 分类结论：产品问题。
• 确认依据：产品缺陷确认旧逻辑在 block job len/offset 连续约 1 分钟不变时判定 ioHung，但客户任务可能停滞约 2 分钟后继续推进。
• 内部追踪：TIC-4663、ZSV-9963、ZSTAC-78162。

问题元数据

• 问题编号：TIC-4663
• 组件/产品：ZVF ZSphere
• 状态：已修复；ZSphere 各维护分支交付矩阵需逐版确认
• 报告/受影响版本：旧 ioHung 判定逻辑；报告环境为大容量 SAN 硬盘备份到 NFS 备份服务器
• 最后更新时间：2026-09-02

问题描述

旧逻辑只要 block job 的 len/offset 在固定短窗口内不变化，就把任务判为 ioHung 并失败。真实存储链路可能只是暂时无进度，稍后仍会继续，因此该判定会产生假阳性。修复改为打印一次“停滞”和一次“恢复”日志而不直接终止；如果是真实 I/O hang，仍允许从 UI 取消任务并由底层 yank 清理。

现象

• zstore/任务错误直接返回 ioHung，但日志中没有对应的 job-cancel 或 yank 记录。
• QMP block job 的 offset 一段时间不动，随后又继续增长；这与永久 I/O hang 不同。
• SAN 硬盘到 NFS 备份服务器的大容量备份更容易暴露长停顿，但存储类型不是产品根因。

影响

仍可恢复的备份被提前标记失败，造成大容量 虚拟机 长时间无法形成新备份；反向地，简单关闭所有 I/O 监测又可能让真实 hang 长期占用任务资源，因此必须使用带日志和 UI 取消能力的正式修复。

规避方案

• 暂无经验证的通用自助参数方案。不要自行关闭监测或改判断时间；固定阈值不能区分临时停顿和真实 I/O hang。

日志与进度确认（只读）

1. 在 ZSphere UI 打开失败任务详情，记录 apiId、虚拟机 UUID、失败时间和所在 ZSphere 主机。SSH 登录管理节点后执行：

   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'

从输出中记录 /vm/volume/takebackup、/imagestore/exportnbdimage 等请求对应的 Agent IP 和 taskuuid/taskUuid。如果当前日志没有结果，继续由同一条命令查询 management-server-日期-序号.log.gz 归档；仍无结果时先核对管理节点和 UUID。

2. 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 'iohung|offset|block job|error|fail|timeout|yank|cancel'

3. SSH 登录虚拟机所在 ZSphere 主机，使用发往该 ZSphere 主机请求行中的 taskuuid 查询 KVM Agent，并用虚拟机 UUID 查看当前 block job；不要误用发往镜像存储（ImageStore）的另一个 taskuuid：

   KB_TASK_UUID='将management-server日志中的taskuuid粘贴到这里'
   KB_VM_UUID='将任务详情中的虚拟机 UUID 粘贴到这里'
   cd /var/log/zstack || exit 1
   zgrep -a -n -C 5 "$KB_TASK_UUID" zstack-kvmagent.log*
   virsh qemu-monitor-command "$KB_VM_UUID" '{"execute":"query-block-jobs","arguments":{}}' --pretty

在任务仍运行时，每隔 30 秒手工重复最后一条只读命令，共保存至少 3 次输出：offset 恢复增长说明旧逻辑可能把临时停顿误判为 ioHung；block job 长期不变且 NFS/SAN 同期持续报 I/O 错误，则先处理真实存储故障。30 秒是取证采样间隔，不是产品判障阈值。任务已经结束时，QMP 返回空列表不能反推当时没有 block job，必须以故障时间窗内的日志为准。

4. 需要上下翻看当前日志时使用 vim -R zstore.log 或 vim -R /var/log/zstack/zstack-kvmagent.log，输入 / 后粘贴 UUID 并按 Enter，按 n 看下一处，输入 :q! 退出。

• 支持协助方案：使用包含该修复的版本或与准确分支匹配的 zstack-store 包。换包前保存原包/校验值和日志，验证一次大盘备份；若新日志仍把短暂停顿直接判失败，回退原包并核对分支。
• 真正持续 hang 时从平台 UI 取消该任务，确认最终触发 yank 且 QMP 无残留；不要直接杀 zstore/QEMU 进程或删除备份 target。
• 验证标准：同一大容量虚拟机的备份能够完成；短暂停顿只记录停滞/恢复而不直接失败；若手工取消真实 hang，任务最终结束且 QMP 不再返回残留 block job。

受影响产品

• ZVF ZSphere：4.10.18 是直接报告/受影响证据点；5.1.0.388 和 5.4.0.1087 仅作为修复模拟验证记录，见“修复状态”。

修复状态

• 当前状态：产品根因和修复方向已确认。
• 修复版本：ZSTAC-78162 记录 5.4.0、4.8.36；ZSV-9942 在 4.10.18 验证；ZSV-12556 在 5.1.0.388 验证。4.10.20 的一次模拟不等同于现场 hang，不能单独作为完整验收。
• 关联缺陷/修复记录：ZSTAC-78162、ZSV-9942、ZSV-9963、ZSV-12556

关联信息

• 关联 TIC/Jira：TIC-4663、ZSV-9963、ZSV-12556、ZSTAC-78162。