UIS内部快照卡在0%，虚拟机状态暂停

修改虚拟机”的任务在任务台卡在0%

1、遇到任务卡住，最好了解一下在此之前这台虚拟机有什么动作，比如这台就有“快照”的动作，记录如下：

2、前台看快照任务是“成功”状态，且快照页签下有显示对应的外部快照，除此之外没有别的任务。那就到后台通过ps -ef|grep <虚拟机名称>看看是否后台有其他进程，比如第三方平台通过调用UIS接口产生的动作，可能不会在前台显示。

如图所示，查询出虚拟机共有4个进程，进程号267789为disk_commit任务（绿色），268047为blockcommit任务（黄色），蓝色为kvm进程也就是该虚拟机的进程，紫色是ps -ef动作对应的进程。如果虚拟机是运行状态且没有任何任务时，正常只会有后两个进程，而disk_commit和blockcommit均为快照过程中可能存在的进程，由此怀疑虽然前台任务台显示任务已成功，实际后台还有进程残留，该“残留”可能是后台任务还在进行，也有可能是真正的进程残留

3、使用virsh qemu-monitor-command <虚拟机id> --pretty  '{ "execute": "query-block-jobs" }'命令（注意pretty后有空格）可以确认外部快照进程在后台还在进行、还是真正的进程残留，其中<虚拟机id>可以通过virsh list --all获得。

现场回显如下，绿色部分回显代表有外部快照任务在进行中，其中红框内的“len”和“offset”分别指“总合并大小”和“当前合并大小”，重复执行此命令可以看到“offset”在不断变化，因此确认该任务还在进行中，offset/len可以计算合并百分比，以此估算剩余时间。此问题查询时发现已经进行到98%左右，下方蓝色部分回显是无快照任务时的回显，也就是说外部快照进度已经真正完毕。

4、对于单台虚拟机来说，任务都是串行进行的，当外部快照任务真正完成后，前台虚拟机的修改任务就正常进行了。

等待即可

此类问题并未影响业务，在处理时不必急于对环境做服务重启或杀进程等动作，以免将问题复杂化。

当然产品也有进步空间，根本原因还是前台任务台进度不准确导致，需要优化