【vCenter】VMware 克隆失败分析报告

这篇文章不是常规的“解决步骤记录”，而是一份基于现场日志和后续分析整理出来的克隆失败排障报告。重点不在于给出一条立即可执行的命令，而在于把问题是如何一步步收敛出来的说明白。

1. 事件背景

反馈在 vCenter 中克隆虚拟机 VM-业务系统-A 时失败，前台报错为：

无法完成文件 .../VM-业务系统-A_12-000002.vmdk 的网络复制
vCenter/Client 侧表现为 vim.fault.NetworkCopyFault

初始现场描述为：

源主机：ESXi-源主机
目标主机：ESXi-目标主机-A
存储：vSAN 数据存储

后续又提供了一个日志包目录：

/Users/<本地>/Downloads/<日志包目录>

对该日志包分析后发现，日志包内对应的某次失败尝试，目标主机并不是 ESXi-目标主机-A，而是 ESXi-目标主机-B。这说明现场至少发生过多次相似失败，症状一致，但目标主机不止一台。

因此，本报告区分两类证据：

现场手工贴出的 目标主机-A 相关日志与命令输出
本地日志包中 目标主机-B 相关的 vCenter/ESXi 证据

二者共同指向同一个核心问题： 失败并非普通网络故障，而是源磁盘在克隆路径中被识别为多层对象链，随后目标端数据移动失败。

2. 核心结论

2.1 最终结论

本次克隆失败的本质不是普通网络通信异常，而是：

克隆过程中，源虚拟机磁盘会生成并参与复制一个临时 delta 链，如 _12-000002.vmdk
目标 ESXi 在处理该源盘时，明确识别到其为：
- multi-link source object chain
因为无法直接进行 object clone，系统回退到 vsansparse movedata / DiskLibCopyDataInt 路径
回退后的目标端数据移动返回：
- Input/output error
vCenter 最终将该底层失败统一包装成：
- vim.fault.NetworkCopyFault

2.2 更精确的表述

当前虚拟机从配置层看是干净的：

当前无快照
当前 get.config 无 _12-000002.vmdk
当前 get.filelayout 无 _12-000002.vmdk
当前磁盘 backing 为 _12.vmdk、_14.vmdk，且 parent = null

但是从克隆执行路径和底层对象行为看，并不干净：

克隆时系统反复生成 _12-000002.vmdk
目标主机日志明确出现 Cannot clone from multi-link source object chain
说明 UI/当前配置干净，并不等于底层克隆执行时对象历史链干净

因此，本问题更准确地定义为：

该 VM 当前配置层干净，但在克隆执行路径中，源盘对象历史仍被解析成多层 linked chain，随后在目标端数据移动阶段失败。

3. 排错过程还原

3.1 第一阶段：先确认是不是 vSAN 全局健康问题

最初先从 vSAN 对象整体健康入手，查看集群对象状态报告。

已知检查结果：

vsan.obj_status_report 显示对象总数约 922
0 inaccessible
0 reduced-availability with no rebuild
0 orphan
未见全局性大面积对象异常

结论：

不是典型的 vSAN 全局对象不可访问导致的普遍性克隆失败
问题更可能集中在某个 VM、某条对象链、或某台目标主机的数据路径

3.2 第二阶段：确认源 VM 当时是否有快照或链异常

最初怀疑该 VM 可能有隐藏快照链。随后逐步检查：

检查 1：文件布局

之前检查 vim-cmd vmsvc/get.filelayout <VM-ID> 时，输出中仅见：

VM-业务系统-A_12.vmdk
VM-业务系统-A_14.vmdk

未见 _12-000002.vmdk 作为当前活动文件布局的一部分。

检查 2：磁盘描述符

之前查看 _12.vmdk 描述符时，关键点为：

parentCID=ffffffff
无 parentFileNameHint

这意味着当前 _12.vmdk 不是显式挂在某个 delta 上的活动子盘。

检查 3：当前快照树

后续执行：

vim-cmd vmsvc/snapshot.get <VM-ID>

输出：

Get Snapshot:

未列出任何快照树。

检查 4：当前设备 backing

后续执行：

vim-cmd vmsvc/device.getdevices <VM-ID>

关键输出摘要：

Hard disk 1 -> [vSAN 数据存储] .../VM-业务系统-A_12.vmdk
- backingObjectId = "<对象ID-磁盘1>"
- parent = null
Hard disk 2 -> [vSAN 数据存储] .../VM-业务系统-A_14.vmdk
- backingObjectId = "<对象ID-磁盘2>"
- parent = null

结论：

从 当前 hostd 配置视角 看，该 VM 的当前快照树和当前设备链是干净的
因此问题不在“当前可见快照树”

3.3 第三阶段：确认失败是否真的发生在 `_12-000002.vmdk`

提供的多处日志表明，失败文件名稳定指向：

VM-业务系统-A_12-000002.vmdk

这非常关键，因为它说明：

出问题的不是当前基盘 _12.vmdk 的文件名本身
而是任务执行期间生成的临时 delta/child disk

源 VM 的 vmware.log* 进一步证明，这个文件不是一次性偶发名，而是长期反复出现的临时可写快照盘。

在后续执行的目录搜索中：

grep -r "_12-000002.vmdk" "/vmfs/volumes/vsan:.../<VM目录UUID>/"

输出中大量命中 vmware.log*，典型日志模式包括：

DISKLIB-LIB_CREATE : CREATE CHILD: "..._12-000002.vmdk"
ToolsBackup: hot adding disk ..._12-000002.vmdk
ToolsBackup: Post-processing writable snapshot disk ..._12-000002.vmdk
SNAPSHOT: SnapshotDeleteNode: Deleting "..._12-000002.vmdk"
DISKLIB-LIB : Disk delete successfully completed

结论：

_12-000002.vmdk 是被频繁创建、使用、删除的临时 delta 盘
它非常像某种 ToolsBackup / quiesce / hot-add 备份一致性流程生成的可写快照盘

3.4 第四阶段：确认目标主机 A 上的真正报错链

现场贴出的目标主机 ESXi-目标主机-A 日志是整个分析的关键转折点。

目标主机 hostd.log / 相关日志中出现了这几类关键信息：

关键报错 1：源链被识别为多层链

日志明确出现：

Cannot clone from multi-link source object chain

这句话是整个问题的最关键证据之一。

它说明：

即使当前 UI 没有快照
即使当前磁盘 backing 没显示 parent
在克隆执行当下，ESXi 仍把源识别为一个多层 linked chain

关键报错 2：回退到数据移动路径

由于无法直接 object clone，日志显示流程回退到 Vmfs_MoveData / DiskLibCopyDataInt。

关键报错 3：目标端 I/O 失败

日志出现：

DiskLibCopyDataInt ... Input/output error
Vmfs_MoveData ... Input/output error
Nfc_DiskLib_Clone ... Input/output error

同时还出现针对 vsansparse 设备的报错：

IOCTLCMD_VMFS_MOVEDATA(3030) failed on '/vmfs/devices/vsansparse/<临时对象路径>' : Input/output error

结论：

失败发生在目标主机的数据移动阶段
NetworkCopyFault 是表层包装
底层真正失败是目标主机读写 vsansparse movedata 时出现 I/O error

3.5 第五阶段：定位临时对象链

基于目标主机-A上的日志，又继续往下追对象 ID。

追到的重要关系包括：

_12-000002.vmdk 对应的对象链并不是单层
前层对象中出现了：
- <临时对象ID-上层链>
再往下又关联到了当前基盘对象：
- <对象ID-磁盘1>

这和 multi-link source object chain 的日志是相互印证的。

后续尝试用 RVC 查询：

vsan.object_info /localhost/Datacenter/computers/Cluster <临时对象ID-上层链>

以及其他变体 UUID，均返回：

Couldn't find info about DOM object '...'

结论：

这些对象更像失败任务期间存在的临时/历史 linked object
失败结束和整合完成后，这些临时对象已从当前 DOM 视图中消失
因此无法再把其精确落到一个当前仍在的 DOM component 上

3.6 第六阶段：确认当前基盘对象本身是否健康

使用 RVC / vSAN 对当前正式对象进行查看，确认如下：

`_12.vmdk` 当前对象

对象 ID：

<对象ID-磁盘1>

通过 vsan.object_info 查到其 RAID1 组件分布健康，组件包括：

一个副本在 ESXi-目标主机-B
一个副本在 ESXi-目标主机-A
witness 在 ESXi-见证主机

`vsan.vm_object_info`

从该 VM 的当前对象视图可见：

VM home 当前健康
_12.vmdk 当前健康
_14.vmdk 当前健康
一些组件确实落在 目标主机-A

结论：

当前正式对象不是“已损坏不可读”的状态
问题更集中在 任务时临时生成/解析出的对象链

3.7 第七阶段：本地日志包分析发现的补充证据

日志包路径：

/Users/<本地>/Downloads/<日志包目录>

分析后发现两个非常重要的补充点。

补充点 1：日志包并非全部对应目标主机-A

在：

/Users/<本地>/Downloads/<日志包目录>/<vCenter日志目录>/var/log/vmware/vsphere-ui/logs/vsphere_client_virgo.log

中，多次看到失败目标主机是：

ESXi-目标主机-B

而不是 ESXi-目标主机-A。

结论：

现场存在多次相似失败
不是只在目标主机-A上出现一次性问题
但目标主机-A上的底层日志最完整，能直达根因路径

补充点 2：曾手工移动过 `_12-000002.vmdk`

在：

/Users/<本地>/Downloads/<日志包目录>/<ESXi源主机日志目录>/var/run/log/shell.log

中，发现于 2026-03-10 10:04:18Z 左右执行过类似：

mv VM-业务系统-A_12-000002.vmdk ./vmsd-bak/

同时，日志包内的对象列表还出现过 _12-000002.vmdk (Missing)。

这说明：

历史上这个临时 delta 盘确实曾被人工干预
这会增强“历史链/对象关系曾被扰动”的怀疑

但需要注意：

这不是当前配置残留的直接证据
更像是历史链异常的加强证据

3.8 第八阶段：确认是否存在“当前配置残留引用”

这是后续重点追问的问题： “这台 VM 是否还存在任何配置/元数据层面对 _12-000002.vmdk 的残留引用？”

为此，在源主机 ESXi-源主机 上执行了三组检查。

检查命令 1：递归搜索 VM 目录

grep -r "_12-000002.vmdk" "/vmfs/volumes/vsan:<数据存储UUID>/<VM目录UUID>"

结果：

大量命中 vmware.log*
命中 .sbc.sf 二进制索引
未见明确 .vmx / .vmsd / 当前 .vmdk descriptor 的活动引用输出

解释：

vmware.log* 只能证明历史上反复出现过该文件
.sbc.sf 属于二进制内部索引，不能当作当前配置残留的可靠证据

检查命令 2：当前 hostd 配置

vim-cmd vmsvc/get.config <VM-ID> | grep -n "_12-000002.vmdk"

结果：

无输出

解释：

当前 hostd 注册配置里，没有 _12-000002.vmdk 活动引用

检查命令 3：当前文件布局

vim-cmd vmsvc/get.filelayout <VM-ID> | grep -n "_12-000002.vmdk"

结果：

无输出

解释：

当前 file layout 也没有把 _12-000002.vmdk 视为活动链的一部分

最终结论：

当前配置层没有残留引用
当前文件布局没有残留引用
问题并不是“现在 .vmx 仍然挂着一个坏 delta”
而是“在任务执行时，系统仍会生成并解析出那条历史/临时对象链”

4. 已证实事实、强相关推断、未证实假设

4.1 已证实事实

以下事实已有明确输出或日志支持：

当前 VM 无可见快照树依据：vim-cmd vmsvc/snapshot.get <VM-ID>
当前 VM 设备层只挂 _12.vmdk 与 _14.vmdk，且 parent = null 依据：vim-cmd vmsvc/device.getdevices <VM-ID>
当前 hostd 配置和 file layout 不含 _12-000002.vmdk 依据：
- vim-cmd vmsvc/get.config <VM-ID> | grep ...
- vim-cmd vmsvc/get.filelayout <VM-ID> | grep ...
_12-000002.vmdk 会在任务执行期间被创建、使用、删除依据：源 VM vmware.log*
目标主机明确报：
- Cannot clone from multi-link source object chain
- Vmfs_MoveData ... Input/output error
- DiskLibCopyDataInt ... Input/output error
- Nfc_DiskLib_Clone ... Input/output error
vCenter 将底层失败包装成 vim.fault.NetworkCopyFault
当前正式对象 _12、_14、VM home 在当前视角健康
集群存在一块 Absent vSAN Disk

4.2 强相关推断

以下判断没有单一一行日志可以完全盖棺定论，但证据链很强：

_12-000002.vmdk 很可能来自 ToolsBackup / guest-consistent / hot-add 类流程依据：ToolsBackup: hot adding disk、Post-processing writable snapshot disk
该 VM 的底层对象历史在 clone workflow 中仍会被识别为多层链依据：multi-link source object chain 与反复创建 _12-000002.vmdk
历史上手工移动 _12-000002.vmdk 可能加剧了对象关系不一致或历史链混乱依据：shell.log 中的手工 mv 记录

4.3 未证实假设

以下内容当前不能下 100% 定论：

Absent vSAN Disk 是否直接承载了失败任务中的临时对象组件
目标主机-A是否是唯一有问题的目标主机因为日志包里也能看到面向目标主机-B的失败
手工移动 _12-000002.vmdk 是否就是本次问题的起点只能说是高风险历史操作，不能直接证明是唯一根因

5. 为什么 Web UI 显示干净，但底层看起来不干净

这是本次排障中最容易误判的点。

Web UI 能说明什么

Web UI 以及 snapshot.get、device.getdevices 能证明：

当前没有活动快照树
当前 VM 的活动设备 backing 是基盘
当前配置没有显式 parent chain

Web UI 不能说明什么

它不能证明：

底层对象历史关系一定简单
clone workflow 里不会临时生成 delta
ESXi 在克隆执行时不会把源盘识别成多层 linked chain

本次现场的真实情况

本次现场更像是：

当前配置层是干净的
但 clone workflow 中仍会创建并解析出一条多层对象链
这条链不是快照管理器当前树状视图能完整反映的

因此：

“UI 视角干净” 与 “克隆执行路径干净” 不是一回事。

6. 根因判断

综合所有证据，最合理的根因表述如下：

该 VM 当前配置层无活动快照，当前设备链显示为基盘；但在克隆执行时，系统仍会为源盘生成并处理临时 delta 链 _12-000002.vmdk。目标主机在处理该源盘时明确将其识别为 multi-link source object chain，无法直接执行 object clone，只能回退到 vsansparse movedata / DiskLibCopyDataInt 路径。回退后在目标端发生 Input/output error，最终由 vCenter 呈现为 vim.fault.NetworkCopyFault。当前正式对象视角健康，说明问题并非简单的当前基盘损坏，更像是克隆执行路径中的历史/临时对象链问题叠加目标端数据移动失败。集群中的 Absent vSAN Disk 是重要风险背景，但尚不能直接证明其为该临时对象的唯一直接触发因素。

7. 处置思路评估

在排障过程中，已讨论过几种可能处理方向，现统一整理如下。

7.1 继续排查“当前是否有隐藏快照”

结论：

这个方向已经基本查到头
当前快照树、当前设备层、当前配置层均显示干净
再继续围绕“当前快照是否存在”深挖，收益已经不高

7.2 常规克隆重试

结论：

不建议继续盲目重试
因为已经有明确底层 multi-link source object chain 与 Input/output error
重试大概率仍踩同一条执行路径

7.3 关机克隆

已补充说明：

关机克隆也尝试过，仍然失败

这说明：

问题并不只是在线克隆时临时快照瞬时产生导致
更可能是底层对象历史链或目标端数据路径本身有问题

7.4 Storage vMotion / Relocate / 变更存储策略

这是一个值得尝试的原位修复思路。

理论价值：

通过迁移或策略变更，让 _12、_14 重新落盘、重写对象 lineage

局限：

如果源盘读路径本身就会失败，Storage vMotion 也可能失败

结论：

值得尝试
但不能保证成功
适合作为“原位重写对象链”的技术方案

7.5 OVF/OVA 导出再导入

这是当前较为实用的绕行方案之一。

价值：

尽量绕开当前 clone workflow
通过导出后再导入，重新生成 VM 配置与目标端对象

风险：

如果导出阶段同样读取到同一条有问题源链，也可能失败

结论：

值得优先尝试
尤其适合“先把业务迁出来”的目标

7.6 新建空白 VM，做业务层/文件层迁移

这是最稳妥但工作量较大的方案。

适用场景：

克隆、迁移、导出导入都不稳定
业务上需要尽快摆脱当前对象链历史

结论：

这是最彻底的绕行方案
但对业务迁移成本最高

8. 推荐操作顺序

结合当前证据，推荐按以下顺序尝试，以提高成功率并尽快恢复业务迁移能力。

方案 A：优先尝试导出/导入

关机
做 OVF/OVA 导出
导出到外部或中转存储
再导入成新 VM
导入时尽量避开 ESXi-目标主机-A，优先选未出现过明显 I/O 异常的主机

适用原因：

能尽量避开当前 clone workflow
对“对象链历史不干净”的场景更友好

方案 B：尝试 Storage vMotion / Relocate / 改存储策略

关机
对该 VM 做一次存储迁移，或至少触发一次对象重写
成功后再尝试克隆

适用原因：

有机会把当前对象 lineage 洗干净

方案 C：直接新建 VM 并迁业务数据

新建空白 VM
通过系统内 Ghost、数据复制、应用迁移、备份恢复等方式迁移业务

适用原因：

最彻底绕过当前历史链

同步动作：处理 vSAN 底层异常

无论采用哪种方案，都建议并行处理：

Absent vSAN Disk
cluster resync 状态
目标主机所在磁盘组 I/O 健康

原因：

这类底层异常虽然未被证实为唯一根因，但明显提高数据移动类任务失败概率

9. 本次排障的最终结语

本次问题最容易被误导的地方，是前台错误写成了“网络复制失败”，而 Web UI 又显示没有快照，容易让人认为：

要么是网络问题
要么只是一次偶发克隆异常

但实际证据表明：

不是普通网络故障
也不是简单的当前活动快照问题
更像是一个“当前配置干净，但底层克隆执行时仍解析到历史/临时多层对象链”的问题

本次排障已经能够明确回答以下问题：

当前 VM 是否有活动快照没有。
当前 VM 配置是否仍残留 _12-000002.vmdk 没有活动残留。
_12-000002.vmdk 是否真实参与失败任务是。
失败是否只是 NetworkCopyFault 这么简单不是，底层是 multi-link source object chain + Vmfs_MoveData / DiskLibCopyDataInt I/O error。
是否已经能给出技术定性可以。

最终定性如下：

该 VM 的当前配置层干净，但在克隆执行路径中，源盘对象历史仍被识别为多层链；目标端在处理这条临时/历史对象链时发生 I/O 失败，最终表现为 NetworkCopyFault。

10. 关键命令与输出摘要

当前快照树

vim-cmd vmsvc/snapshot.get <VM-ID>

输出：

Get Snapshot:

当前设备 backing

vim-cmd vmsvc/device.getdevices <VM-ID>

关键摘要：

Hard disk 1 -> _12.vmdk -> backingObjectId = <对象ID-磁盘1> -> parent = null
Hard disk 2 -> _14.vmdk -> backingObjectId = <对象ID-磁盘2> -> parent = null

当前配置是否残留 `_12-000002.vmdk`

vim-cmd vmsvc/get.config <VM-ID> | grep -n "_12-000002.vmdk"

输出：无

当前 file layout 是否残留 `_12-000002.vmdk`

vim-cmd vmsvc/get.filelayout <VM-ID> | grep -n "_12-000002.vmdk"

输出：无

VM 目录中是否出现过 `_12-000002.vmdk`

grep -r "_12-000002.vmdk" "/vmfs/volumes/vsan:.../<VM目录UUID>/"

关键命中：

CREATE CHILD: "..._12-000002.vmdk"
ToolsBackup: hot adding disk ...
Post-processing writable snapshot disk ...
SnapshotDeleteNode: Deleting ...

目标主机关键失败证据

关键日志语义：

Cannot clone from multi-link source object chain
IOCTLCMD_VMFS_MOVEDATA ... Input/output error
DiskLibCopyDataInt ... Input/output error
Nfc_DiskLib_Clone ... Input/output error

1. 事件背景

2. 核心结论

2.1 最终结论

2.2 更精确的表述

3. 排错过程还原

3.1 第一阶段：先确认是不是 vSAN 全局健康问题

3.2 第二阶段：确认源 VM 当时是否有快照或链异常

检查 1：文件布局

检查 2：磁盘描述符

检查 3：当前快照树

检查 4：当前设备 backing

3.3 第三阶段：确认失败是否真的发生在 _12-000002.vmdk

3.4 第四阶段：确认目标主机 A 上的真正报错链

关键报错 1：源链被识别为多层链

关键报错 2：回退到数据移动路径

关键报错 3：目标端 I/O 失败

3.5 第五阶段：定位临时对象链

3.6 第六阶段：确认当前基盘对象本身是否健康

_12.vmdk 当前对象

vsan.vm_object_info

3.7 第七阶段：本地日志包分析发现的补充证据

补充点 1：日志包并非全部对应目标主机-A

补充点 2：曾手工移动过 _12-000002.vmdk

3.8 第八阶段：确认是否存在“当前配置残留引用”

检查命令 1：递归搜索 VM 目录

检查命令 2：当前 hostd 配置

检查命令 3：当前文件布局

4. 已证实事实、强相关推断、未证实假设

4.1 已证实事实

4.2 强相关推断

4.3 未证实假设

5. 为什么 Web UI 显示干净，但底层看起来不干净

Web UI 能说明什么

Web UI 不能说明什么

本次现场的真实情况

6. 根因判断

7. 处置思路评估

7.1 继续排查“当前是否有隐藏快照”

7.2 常规克隆重试

7.3 关机克隆

7.4 Storage vMotion / Relocate / 变更存储策略

7.5 OVF/OVA 导出再导入

7.6 新建空白 VM，做业务层/文件层迁移

8. 推荐操作顺序

方案 A：优先尝试导出/导入

方案 B：尝试 Storage vMotion / Relocate / 改存储策略

方案 C：直接新建 VM 并迁业务数据

同步动作：处理 vSAN 底层异常

9. 本次排障的最终结语

10. 关键命令与输出摘要

当前快照树

当前设备 backing

当前配置是否残留 _12-000002.vmdk

当前 file layout 是否残留 _12-000002.vmdk

VM 目录中是否出现过 _12-000002.vmdk

目标主机关键失败证据

3.3 第三阶段：确认失败是否真的发生在 `_12-000002.vmdk`

`_12.vmdk` 当前对象

`vsan.vm_object_info`

补充点 2：曾手工移动过 `_12-000002.vmdk`

当前配置是否残留 `_12-000002.vmdk`

当前 file layout 是否残留 `_12-000002.vmdk`

VM 目录中是否出现过 `_12-000002.vmdk`