问

超融合UIS平台精简转延迟置零，三级镜像合并卡在99%如何解决？

UIS超融合

5小时前提问

0关注
0收藏，38浏览

zhiliao_6h91bE

zhiliao_6h91bE 零段

粉丝：0人关注：0人

问题描述：

环境：平台版本为 V7.0 (E0750P08H01)，之前扩容磁盘空间时选择了“精简配置”，现在需要改为“延迟置零”。

问题：由于该镜像存在三级镜像结构，执行合并后，进度卡在 99% 。

除了强行终止进程，是否有其他方法可以推动合并完成？
类似 8T 大小的卷，在正常情况下这类合并一般需要多长时间？

3 个回答

按时间按赞数

zhiliao_Gixe

zhiliao_Gixe 二段

粉丝：2人关注：9人

问题分析：
精简转延迟置零（三级镜像）合并卡在99%，通常是因为底层数据块迁移或元数据更新阶段遇到资源瓶颈或软性错误，进程并未完全停止，但进展极其缓慢。

排查与解决步骤：
1. 检查合并任务状态与资源：
# 在CVM节点执行
uiscmd vm list # 确认虚拟机状态
uiscmd vm-disk list --vm-id <虚拟机ID> # 查看目标磁盘详细状态
uiscmd task list # 查看后台任务列表及状态
重点关注存储池的IOPS、带宽和延迟，以及CVM节点的CPU、内存使用率。资源饱和是常见原因。

2. 尝试恢复合并进程：
* 临时调整策略：如果资源饱和，可尝试在业务低峰期进行。
* 重启相关服务：有时可解除软锁。
# 在CVM节点执行，按顺序重启服务
systemctl restart uis-hypervisor
systemctl restart uis-conductor
* 检查底层存储：通过`iostat -x 1`查看物理磁盘利用率，确认是否存在慢盘或故障盘。

3. 强制终止作为最后手段：
如果上述方法无效，且任务长时间无进展，可强制终止后重新发起转换。操作前务必对虚拟机创建快照或备份。
uiscmd task cancel <任务ID> # 取消合并任务
任务取消后，建议先检查并修复可能存在的存储问题，再重新发起“精简转延迟置零”操作。

关于8T卷合并时间：
没有绝对标准时间，它取决于：
数据实际写入量：精简卷的已分配容量，而非总容量。
存储性能：磁盘类型（SSD/HDD）、RAID级别、存储网络带宽。
系统负载：并发IO操作。
在性能良好的全闪存存储上，已分配数据量较大的8T卷，合并过程也可能需要数小时甚至更久。卡在99%的阶段通常是在进行最终的元数据提交，正常情况下不应过长（例如超过1-2小时）。

暂无评论

国服第181小鱼人

国服第181小鱼人六段

粉丝：7人关注：0人

对于您UIS平台上8T大容量磁盘从精简转延迟置零，三级镜像合并卡在99%的问题，强行终止进程虽然是最后手段，但确实不是唯一办法。这种情况通常可以通过后台检查、手动修复镜像链或直接转换格式来解决

第一步：后台确认合并是否真的“卡死”还是“仍在处理”

不要仅依赖Web界面的进度百分比，建议通过SSH登录到UIS底层主机（CVM或CVK节点）进行确认。

检查合并任务进程：
执行以下命令，查看是否有qemu-img相关的进程在运行。如果看到进程且CPU或IO有持续变化，说明任务仍在后台进行，只是Web界面刷新问题，建议继续等待。
ps aux | grep qemu-img
检查虚拟磁盘块设备状态：
使用以下命令查看虚拟机磁盘的当前状态，确认是否有“mirroring”或“commit”状态未完成。
# 先找到虚拟机ID
virsh list --all # 查看指定虚拟机的磁盘状态 virsh qemu-monitor-command <虚拟机ID> --hmp --cmd "info block

第二步：如果确认任务卡死，推动合并的两种方法

如果上述检查确认qemu-img进程已不存在或无IO变化，说明任务确实卡死，可以采用以下方法解决：

方法一：手动终止卡死任务并修复镜像链（适用于三级镜像）

如果合并任务卡死，UIS平台上可能会残留锁定状态。您可以按以下步骤操作：

终止卡死的进程：
在主机上找到并强制终止卡死的qemu-img进程。
ps aux | grep qemu-img | grep -v grep
kill -9 <PID>
检查并修复镜像链关系：
进入虚拟机磁盘文件所在目录（通常在 /vms/images/ 下），使用qemu-img info命令查看三级镜像的链条关系。
qemu-img info /path/to/vdb.qcow2 如果输出显示 backing file 链断裂或异常，需要使用qemu-img rebase修复链条指向：
qemu-img rebase -b /path/to/base.qcow2 /path/to/top.qcow2

方法二：采用“迂回”方案，直接转换磁盘格式（推荐，更彻底）

为了避免平台合并功能的未知问题，最稳妥、成功率最高的方式是绕过UIS平台的合并功能，直接在后端通过命令转换磁盘格式，一步到位实现“延迟置零”（预分配）。

关闭虚拟机：这是关键前提，转换前必须关机。
定位磁盘文件：通过Web界面或find命令，找到该虚拟机8T磁盘对应的 .qcow2 文件路径。
执行转换命令：
使用qemu-img convert命令，强制将精简格式的镜像（及其所有依赖的快照链）转换为一个新的、完整的“预分配”格式镜像。
# -p 显示进度；-o preallocation=full 指定为延迟置零（预分配）
qemu-img convert -p -f qcow2 -O qcow2 -o preallocation=full /原路径/disk.qcow2 /新路径/disk_new.qcow2

替换磁盘文件：
转换完成后，在UIS平台上将虚拟机的原磁盘分离，然后重新挂载这个新生成的 disk_new.qcow2 文件。

第三：关于8T卷的合并时间

对于8T大小的卷，无论是由平台自动合并，还是使用qemu-img convert手动转换，所需时间都非常长，以“天”为单位计算，进度卡在99%也可能是耗时长的正常表现。

预估时间：在普通机械硬盘（HDD）环境下，处理8T数据通常需要 24小时到72小时 不等，具体取决于存储性能（IOPS）。
核心因素：
- 数据量：虽然磁盘显示8T，但实际写入的数据量是多少？合并只会处理实际占用的空间，如果实际数据只有2T，时间会相应缩短。
- 存储性能：如果是万兆网络+SSD缓存加速的环境，速度会快很多；如果是千兆网络+SATA机械盘，时间会非常长。
关键提示：合并期间由于要重新计算镜像哈希值，耗时很长是正常现象，在此期间建议关闭Web界面，任务会自动在后台运行，无需反复刷新或干预