esxcli命令迁移VMware虚拟机的核心逻辑是：在目标主机上识别并重新挂载原有数据存储，而不是真正”移动”虚拟机文件本身。它绕过了vCenter，直接在ESXi主机层面操作存储，最适合vCenter不可用、跨集群存储迁移或故障恢复应急等场景，整个过程依赖命令行，对操作者的存储路径理解要求较高，下面拆解具体步骤与避坑要点。
esxcli迁移虚拟机与vMotion怎么选
很多管理员纠结”到底用esxcli还是vMotion”，选择标准其实很直接。vMotion要求vCenter管理、共享存储、兼容CPU和网络，且虚拟机处于开机状态，esxcli则完全相反，它不需要vCenter，只需要SSH或DCUI命令行访问权限，但虚拟机必须关机。
适合esxcli迁移虚拟机的典型场景包括：
- vCenter损坏或临时不可用，生产环境急等恢复
- 虚拟机文件所在存储整列故障,需要换新存储再挂载
- 从本地存储迁移到共享存储,且不需要在线服务
- 跨vCenter的冷迁移,不想用OVF模板导出导入
从成本角度看,vMotion依赖企业版许可证，而esxcli是免费的底层工具，对预算有限的中小企业机房租用场景更友好，不过操作门槛高，误删数据存储或卸载错设备会直接导致数据丢失，这一点心里要有数。
vMotion使用门槛对比
vMotion需要满足的条件业内共识包括：CPU必须兼容（同代或启用EVC）、虚拟机网络端口组在目标主机存在、存储为共享式且经过VMFS或NFS挂载，esxcli迁移完全没有这些硬件层校验，只要能SSH登录、能识别存储设备名，就能操作。
有疑问的人常问”esxcli能在线迁移吗”，答案是不能，esxcli迁移虚拟机的本质是存储设备重新挂载，期间虚拟机必须处于关机状态（除非做Storage vMotion，那是vCenter的活，与esxcli无关），如果你需要业务不中断，老老实实走vMotion路线。
esxcli迁移虚拟机的准备工作与具体步骤
以”将虚拟机从ESXi-A迁移到ESXi-B，数据存储在共享磁盘阵列”为例，实操逻辑是：在A上卸载数据存储，在B上扫描并挂载同名数据存储，然后注册虚拟机，具体命令如下。
迁移前检查清单
以下准备工作漏掉任何一项都可能导致迁移失败：
- 确认ESXi主机SSH服务已开启（Troubleshooting Options → Enable SSH）
- 确认目标主机有足够的CPU和内存资源承载虚拟机
- 记录虚拟机当前所在数据存储名称和虚拟机文件目录名
- 确认共享存储已正确连接到两台主机（FC或iSCSI）
- 在vCenter中关闭虚拟机电源并移除清单,但保留磁盘文件
虚拟机关机不是直接断电,建议在客户机操作系统内执行优雅关机，避免文件系统损坏。
在源主机上卸载数据存储
登录源主机后,先用esxcli storage vmfs extent list查看所有VMFS卷和设备映射关系，找到目标数据存储对应的设备ID（例如naa.6000xxxx或mpx.vmhba1:C0:T1:L0），然后执行：
esxcli storage vmfs unregister --volume-label=你的数据存储名称此命令只从ESXi中移除数据存储识别信息,不会删除物理磁盘上的任何数据，卸载后建议执行esxcli storage core device rescan --all刷新存储视图，再在目标主机上确认设备可见。
需要特别指出的是,如果是本地磁盘上的虚拟机迁移，以上命令不适用，因为本地存储物理上不在目标机上，你需要先vmkfstools -i克隆磁盘到共享存储，或者用scp/vifs拷贝vmdk文件，这属于文件级复制而非存储重挂载，不在esxcli直接迁移范围内。
在目标主机上挂载数据存储
在目标主机上,先执行esxcli storage core adapter rescan --all让系统感知新接入的存储设备，然后查看esxcli storage vmfs snapshot list或esxcli filesystem volume list确认能否识别到未挂载的VMFS卷。
如果卷未自动挂载,手动执行：
esxcli storage vmfs register --volumes=naa.6000xxxx这里的naa.xxxx对应共享存储上的VMFS分区设备ID，命令执行后，用esxcli storage filesystem list验证卷是否已挂载到/vmfs/volumes/目录下，并找到虚拟机的.vmx文件路径。
注册虚拟机到目标主机清单
最后一步通过vSphere Web Client或命令行完成虚拟机注册，命令行为：
vim-cmd solo/registervm /vmfs/volumes/存储名/虚拟机目录/虚拟机.vmx注册完成后,检查虚拟机的网络适配器是否连接到目标主机上存在的端口组。
端口组名称可能因交换机和标准虚拟交换机不同而不一致，如果连不上，需要在目标主机上重新配置网络标签再开机。
esxcli迁移虚拟机最容易忽视的注意事项
esxcli迁移虚拟机出问题,90%的情况都集中在以下三个环节。
存储设备名称不一致导致的挂载失败
同一物理存储到两台主机的设备路径可能不同（比如一台走vmhba2，另一台走vmhba3），但最终解析到的naa.xxxx是全局唯一的，操作时只认naa开头的WWID，不要依赖mpx.vmhba这类路径名，遇到挂载后卷显示为”未知”或不一致状态，先检查两台主机的HBA卡驱动和固件版本。
RDM裸设备映射的特殊处理
如果虚拟机使用了RDM（裸设备映射）磁盘，esxcli storage vmfs unregister只移除VMFS卷本身的挂载，RDM映射文件仍然存在于原数据存储，迁移后的虚拟机会因为找不到RDM映射文件而报错，此时需要手动重新创建RDM映射，或确保目标主机能访问到同一LUN并重新配置磁盘映射关系，部分虚拟机在注册后开机时提示”SCSI设备不可用”就是这个原因。
数据存储重命名后虚拟机的路径依赖
目标主机挂载数据存储时,如果原名为datastore1，而目标机上已存在另一个datastore1，系统会自动重命名为datastore1 (1)。虚拟机的.vmx文件中记录的绝对路径如果不匹配，注册时必然失败，遇到这种情况，用vim-cmd solo/registervm注册后，再通过vim-cmd vmsvc/reload重新加载配置，或者用sed修改.vmx中的路径字段。
一个容易被忽略的注意事项是：迁移完成后不要立即删除源数据存储的虚拟机文件，建议在目标主机上正常运行数天，确认无IO错误和快照异常后再清理，避免因隐藏依赖导致数据彻底无法找回。
对于本地存储到本地存储的迁移,esxcli则无能为力，需要用vmkfstools -i克隆或vifs --get下载再上传，过程繁琐且耗时长。
核心操作命令速查表
| 操作场景 | 命令 | 备注 |
|---|---|---|
| 查看VMFS卷映射 | esxcli storage vmfs extent list |
记录设备naa ID |
| 卸载数据存储 | esxcli storage vmfs unregister -l 存储名 |
不删数据 |
| 重新扫描存储设备 | esxcli storage core device rescan --all |
目标主机执行 |
| 注册已挂载的VMFS卷 | esxcli storage vmfs register --volumes=naa.ID |
手动挂载时用 |
| 查看已挂载卷 | esxcli storage filesystem list |
确认路径 |
| 注册虚拟机 | vim-cmd solo/registervm 路径/vmx |
需完整路径 |
这些命令在ESXi 6.5到8.0版本中均通用，未发现语法层面的破坏性变更。
esxcli迁移虚拟机常见问题解答
esxcli迁移后虚拟机开机提示找不到磁盘怎么办
首先确认vmdk文件是否存在于数据存储的目录中,执行ls /vmfs/volumes/存储名/虚拟机目录/查看是否有-flat.vmdk和.vmdk描述文件，若文件存在，检查.vmdk描述文件中的VMFS参数是否指向正确的设备路径，必要时用vmkfstools -E修复磁盘描述，再检查主机HBA卡是否识别到所有LUN，大多数情况下，重扫存储并重新注册虚拟机即可解决。
esxcli迁移与vMotion的迁移时间差距有多大
esxcli的存储重挂载过程实际耗时通常只有几分钟（取决于存储扫描速度和设备数量），因为没有数据复制过程，而vMotion需要将内存和磁盘内容完整传输到目标端，千兆网络下迁移一台40GB磁盘、8GB内存的Windows虚拟机大约需要10到20分钟，若共享存储后端本身性能不足，esxcli的挂载时间反而会更短，这点在存储性能较差的场景中差异尤其明显。
esxcli迁移需要目标主机提前创建什么
需要提前确认目标主机上存在虚拟机所需的虚拟交换机端口组,如果虚拟机使用VLAN网络，目标主机上没有对应的端口组ID，迁移后虚拟机网络断开且无法自动恢复，建议迁移前在目标主机上创建同名端口组或标准交换机，确保MAC地址和VLAN标签一致，vMotion也要求满足同样的网络条件，这是虚拟化环境中最常见的迁移前配置遗漏。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/624501.html
