ESXi 6.7 导出虚拟机文件夹导入 Hyper-V 完整实战教程 2026

一、为什么需要把 ESXi 虚拟机迁移到 Hyper-V

跨虚拟化平台迁移,这事说起来像”换门牌号码”,真做起来才知道坑多得能写一本书。但企业里偏偏经常要做这件事——VMware 被博通收购后授权策略反复调整,Hyper-V 凭借 Windows Server 自带的零成本优势,成了不少企业”降本”的首选方案。还有些场景是被客户要求、混合云架构调整、ESXi 硬件老化需要淘汰等等。

先理清一个核心问题:VMware 和 Microsoft 的虚拟化产品到底”不兼容到什么程度”。这两家底层用的是完全不同的虚拟硬件栈:

组件	VMware ESXi	Microsoft Hyper-V
磁盘格式	VMDK(Virtual Machine Disk)	VHD / VHDX
虚拟网卡	VMXNET3、E1000	Hyper-V 虚拟网卡(旧版叫”旧版网络适配器”)
存储控制器	PVSCSI、LSI Logic、SATA AHCI	IDE(Gen1)、SCSI(Gen2)
虚拟 CPU	VMware 虚拟 CPU 指令集	Hyper-V 虚拟 CPU 指令集
配置描述	VMX 文件 + VMDK	XML 配置 + VHDX
导出格式	OVF / OVA(标准开放格式)	无对等开放格式,需手动打包

看到差异就知道,这不是简单的”换个文件后缀”——磁盘格式、虚拟硬件、配置描述全都得变。但好消息是:CPU 指令集层面,x86/x64 平台的 CPU 指令集是行业标准的,只要操作系统是 Windows 或主流 Linux,迁移后操作系统本身不需要重装。这就是迁移可行的根本基础。

二、迁移原理与文件格式详解

动手前,先理清三种磁盘格式的差异,避免后面工具选错。

2.1 VMDK:VMware 的磁盘格式

VMDK(VMware Virtual Machine Disk)是 VMware 的虚拟磁盘格式,本质是一个文件,但内部可以拆成多个 2GB 的小文件(-s001、-s002…)以兼容老式 FAT32 文件系统。VMDK 有几种类型:

• thick provisioned(厚置备):创建时就分配全部空间,性能最稳。
• thin provisioned(精简置备):按需占用空间,适合存储紧张场景。
• rdm(Raw Device Mapping):直接映射物理磁盘,不是文件,无法直接转换,需要先转 VMDK。
• sesparse(sparse extent with zero/small grain):ESXi 5.5+ 引入的高效精简格式,占空间更小。

Hyper-V 转换工具最常遇到的是 -flat.vmdk(实际数据文件)和 .vmdk(描述文件)两个,转换前要把它们合并成一个 VMDK 才能转。

2.2 VHD 与 VHDX:Hyper-V 的磁盘格式

VHD 是微软自 Virtual PC 时代就在用的格式,VHDX 是 Windows Server 2012 引入的新格式(.vhdx 后缀),支持最大 64TB 单文件、内置日志防断电损坏、性能更好。建议统一转成 VHDX。VHDX 还分两种:

• 动态扩展(Dynamically expanding):默认,文件按需增长,适合大多数场景。
• 固定大小(Fixed size):创建时就占满全部空间,性能最好,数据库等 IO 密集型 VM 推荐。

2.3 OVF/OVA:开放虚拟化格式

OVF(Open Virtualization Format)是业界标准的虚拟机打包格式,由 DMTF 制定,本质上是一个 XML 描述文件 + 一堆 VMDK 磁盘文件,用文件夹组织。OVA 是 OVF 的单文件版,把整个文件夹打包成 .ova(本质是 tar 压缩包)。

关键点:OVF/OVA 是开放格式,理论上 Hyper-V 也能导入,但实际上导入体验非常糟糕——Hyper-V 的 OVF 导入功能残缺,网络配置、虚拟硬件映射都需要手动调整。所以业内通行的做法是:从 ESXi 导出 OVF/OVA → 解包得到 VMDK → 把 VMDK 转成 VHDX → 在 Hyper-V 里导入。

三、ESXi 6.7 端导出虚拟机的三种方式

ESXi 6.7 提供了三种导出方式,适用场景不同。

3.1 方式一:导出 OVF/OVA(推荐)

最规范、最通用的导出方式。在 vSphere Client(HTML5 版)里:

1. 关闭目标 VM(导出前必须关,运行中的 VM 导出会有数据不一致风险)。
2. 在 VM 上右键 → “模板” → “导出 OVF/OVA 模板”。
3. 选择导出位置(可以保存到本地磁盘,也可以保存到 ESXi 主机的某个 datastore 通过浏览器下载)。
4. 格式选择:OVA(单文件) 适合单台 VM、传输一次完成;OVF(文件夹) 适合多台 VM 或大文件(超过 4GB 时浏览器对单文件下载有限制)。
5. 等待导出完成,得到 VM名.ova 文件或 VM名.ovf + *.vmdk 文件夹。

命令行等价做法(SSH 到 ESXi):

# 关闭 VM
vim-cmd vmsvc/power.off <vmid>

# 导出 OVF 模板(需要先启用 SSH)
ovfvi --server=esxi-host --username=root --password=xxx \
  --vmPath=/vmfs/volumes/datastore1/MyVM/MyVM.vmx \
  --target=/vmfs/volumes/datastore1/export/MyVM.ova \
  --diskMode=thin

注意 ovfvi 是 ESXi 自带工具,但功能有限。社区推荐用 VMware OVF Tool(单独下载的客户端工具),功能更稳定。

3.2 方式二:直接下载 VMDK 文件(快速但需要手动处理)

绕过 OVF 打包,直接从 ESXi datastore 里把 VMDK 文件拷出来。操作步骤:

1. 关闭 VM。
2. 用 vSphere Client 打开 ESXi 的 datastore 浏览器,定位到 /vmfs/volumes/datastore1/VM名/ 目录。
3. 下载所有 .vmdk 文件,包括 VM名.vmdk(描述文件)和 VM名-flat.vmdk(数据文件),还有 VM名.nvram(BIOS 配置)和 VM名.vmx(配置文件)。
4. 用 SCP 命令下载更稳定:

   scp root@esxi:/vmfs/volumes/datastore1/MyVM/* .

注意:这个方式跳过 OVF 打包,适合 OVA 文件太大无法下载的场景。但因为没有 OVF 描述文件,VMX 配置需要后续在 Hyper-V 重新配置(虚拟硬件、内存、CPU 数等)。

3.3 方式三:用 vCenter Converter(整盘迁移)

VMware vCenter Converter Standalone 是免费工具,能把运行中的物理机或其他格式 VM 直接转换成 VMware 格式。反向(VMWare → 其他平台)它不支持直接转,但可以输出 OVF 文件再手动处理。

这种方式适合已经停服、着急迁移的场景。一般不推荐,优先用方式一。

3.4 三种方式对比

方式	优点	缺点	适用场景
OVF/OVA 导出	标准化、自动包含所有配置	大文件导出耗时长	常规迁移(推荐)
直接下载 VMDK	速度最快、无中间步骤	丢失 VMX 配置,需手动恢复	大文件应急、OVF 失败时
vCenter Converter	可热迁移运行中 VM	反向能力弱、依赖网络稳定	已停服急迁

四、VMDK 转 VHDX:三种工具详解

拿到 VMDK 后,核心工作就是把它转成 Hyper-V 能用的 VHDX。这一步有三种工具可选。

4.1 方式一:StarWind V2V Converter(图形界面,推荐新手)

StarWind V2V Converter 是免费工具,支持多种虚拟磁盘格式互转,Windows GUI 操作,体验最好。

操作步骤:

1. 下载安装:从 StarWind 官网下载免费版(注册后获取下载链接)。
2. 打开 V2V Converter → “Next” → 选择源格式 “VMware VMDK”。
3. 选 VMDK 文件(如果是 OVA 包的,先解压得到 .vmdk 文件)。
4. 选目标格式 “Microsoft VHDX”。
5. 选 VHDX 类型:”Dynamically expanding”(动态扩展)或 “Fixed size”(固定大小)。生产环境数据库 VM 推荐固定大小。
6. 选目标位置:Hyper-V 主机能访问的路径,或直接选 Hyper-V 主机上的某个 VHD 目录。
7. 点 “Convert” 开始转换。

实测转换速度:100GB 的 VMDK 在 SSD 上大约 8-15 分钟。CPU 占用高,但磁盘 IO 不重。

4.2 方式二:qemu-img(命令行,推荐批量和脚本化)

qemu-img 是 QEMU 项目的一部分,功能强大的磁盘格式转换工具,几乎支持所有虚拟磁盘格式互转。Windows 上有官方编译版。

下载安装:从 qemu.weilnetz.de 下载 Windows 64 位版,解压到 C:\qemu\。

基本命令:

# VMDK 转 VHDX(动态扩展)
qemu-img convert -f vmdk -O vhdx -o subformat=dynamic "D:\source\MyVM.vmdk" "D:\output\MyVM.vhdx"

# VMDK 转 VHDX(固定大小,数据库 VM 推荐)
qemu-img convert -f vmdk -O vhdx -o subformat=fixed "D:\source\MyVM.vmdk" "D:\output\MyVM.vhdx"

# OVA 转换(无需先解压)
qemu-img convert -f vmdk -O vhdx "D:\source\MyVM.ova" "D:\output\MyVM.vhdx"

# 批量转换 PowerShell 脚本
Get-ChildItem "D:\vmdk-files\*.vmdk" | ForEach-Object {
    $outName = $_.BaseName + ".vhdx"
    Write-Host "Converting $($_.Name) ..."
    & "C:\qemu\qemu-img.exe" convert -f vmdk -O vhdx -o subformat=dynamic $_.FullName "D:\output\$outName"
}

注意:qemu-img 在转换 sparse 文件(thin VMDK)时会自动识别并跳过零块,转换出来的 VHDX 也是稀疏的,占用空间只有 VMDK 实际用到的部分。

4.3 方式三:Hyper-V 自带的 Convert-VHD(需要 Hyper-V 环境)

如果你已经在 Hyper-V 主机上工作,可以直接用 PowerShell 的 Convert-VHD 命令。但这个命令不能直接读 VMDK,需要先用 StarWind 或 qemu-img 转一次成 VHD/VHDX,再用 Convert-VHD 调整格式或压缩。

# VHDX 固定大小转动态扩展(节省空间)
Convert-VHD -Path "D:\VMs\MyVM.vhdx" -DestinationPath "D:\VMs\MyVM-dynamic.vhdx" -VHDType Dynamic

# VHDX 压缩(去除空洞)
Optimize-VHD -Path "D:\VMs\MyVM.vhdx" -Mode Full

4.4 三种转换工具对比

工具	图形/命令行	支持源格式	批量能力	推荐场景
StarWind V2V	图形	VMDK/VHD/VHDX/QCOW2/RAW	弱(单任务)	新手单台转换
qemu-img	命令行	几乎所有格式	强(脚本化)	批量、自动化
Convert-VHD	PowerShell	VHD/VHDX 之间	强	VHDX 格式优化

最佳实践:qemu-img 完成 VMDK → VHDX 转换,Convert-VHD 完成后续优化(如动态/固定切换)。StarWind 适合零星单台转换。

五、Hyper-V 端导入与首次启动

VHDX 准备好后,下一步是在 Hyper-V 上创建 VM 并挂载磁盘。

5.1 创建新 Hyper-V 虚拟机

1. 打开 Hyper-V 管理器 → 右侧”新建” → “虚拟机”。
2. 名称:和原 VM 保持一致,便于识别。
3. 指定代数:Gen 1(传统 BIOS/MBR) 或 Gen 2(UEFI/GPT)。原 ESXi VM 用什么代际,这里要选对应:
   • 原 VM 是 BIOS + MBR 启动 → 选 Gen 1。
   • 原 VM 是 UEFI + GPT 启动(Windows 10/11 默认、Linux 现代发行版常见) → 选 Gen 2。
4. 分配内存:和原 VM 一致或略多。Gen 2 才支持动态内存。
5. 配置网络:选 Hyper-V 的虚拟交换机(后面会专门讲网卡迁移)。
6. 虚拟硬盘:选 “稍后连接虚拟硬盘”(关键,这一步不要新建 VHDX,我们要用转换好的 VHDX)。
7. 完成向导。

5.2 挂载转换好的 VHDX

1. 在新建好的 VM 上右键 → “设置” → 左侧 “SCSI 控制器”(Gen 1 是 IDE)→ “硬盘驱动器” → “添加”。
2. 选 “虚拟硬盘” → “浏览” → 选转换好的 .vhdx 文件。
3. 确认。VHDX 已作为 VM 的启动磁盘挂载。

如果 VM 有多个磁盘,每个磁盘都要单独挂载一次,注意控制器类型(IDE vs SCSI)和原 VM 的对应关系。

5.3 处理”无法启动”问题

第一次启动 VM 大概率会出问题。常见情况:

症状 A:开机黑屏,提示 “Boot failure”。
原因:Gen 1/Gen 2 选错了,或者启动顺序没指对。
修法:关机 → 设置 → BIOS/固件(Gen 2 是”安全启动”前的”集成固件”)→ 把 VHDX 所在的控制器调成第一启动项。

症状 B:启动后蓝屏 0x0000007B(INACCESSIBLE_BOOT_DEVICE)。
原因:Windows 的存储控制器驱动不匹配。原 VM 用 PVSCSI,Hyper-V 用了 SCSI,Windows 启动时找不到磁盘。
修法:开机按 F8 进安全模式,Windows 会自动加载标准驱动修复,或者手动注入 Storport 驱动。

症状 C:启动后停在 “Starting Windows” 或卡死。
原因:Windows 检测到硬件大幅变化(主板、磁盘控制器、CPU 都变了),触发”sysprep”重置流程但没跑完。
修法:进安全模式卸载 VMware Tools 和不兼容驱动后重启。

5.4 网络配置

启动后网络大概率不通,因为 VMware 的 VMXNET3 网卡驱动和 Hyper-V 不兼容。需要做几件事:

1. 在 Hyper-V 设置里把网络适配器类型改为 “网络适配器”(不要用”旧版网络适配器”,兼容性差)。
2. 在 Windows VM 里卸载 VMware Tools(控制面板 → 程序 → 卸载 VMware Tools),重启。
3. Windows 会自动识别 Hyper-V 的”Microsoft Hyper-V Network Adapter”,安装驱动,网络恢复。
4. 如果是 Linux VM,内核会自动加载 Hyper-V 的 netvsc 驱动(hv_netvsc),无需手动装驱动。

5.5 卸载 VMware Tools 和清理

迁移成功后,还需要清理残留的 VMware 痕迹,避免后续问题:

• Windows VM:控制面板 → 卸载程序 → 卸载 “VMware Tools”。如果装了 “VMware SVGA 3D” 等额外驱动,一起卸载。
• Linux VM:vmware-uninstall-tools.pl 脚本删除 VMware 用户态工具;内核模块在重启后会自动卸载。
• 删除 VMXNET3 网卡的旧驱动:pnputil /remove-device "PCI\VEN_15AD&DEV_0710"。

六、实战案例:Windows Server 2019 VM 完整迁移

把前面的内容串起来,完整跑一遍实战。

6.1 案例背景

假设有一台 Windows Server 2019 VM,跑在 ESXi 6.7 上,配置如下:

• 2 vCPU、8GB 内存
• 系统盘 100GB(thick provisioned)、数据盘 500GB(thin provisioned)
• BIOS 启动(MBR 分区)
• 网络走 VMXNET3 网卡,绑了 192.168.10.x/24 网段
• 运行 IIS + SQL Server 2017,正在被用户访问

迁移目标:Hyper-V 2022 上,保持业务可用,IP 保持原样。

6.2 完整迁移步骤

阶段 1:ESXi 端准备(预计 30 分钟)

1. 通知用户维护窗口(必须在 23:00 后,业务低峰期)。
2. 关闭 VM,确认电源状态 “Powered Off”。
3. 删除 VM 快照(快照会显著增加 VMDK 文件大小)。
4. vSphere Client → VM 右键 → 导出 OVF 模板。
5. 选择保存到本地工作站,格式选 OVF(文件夹)。
6. 等待导出完成(100GB+500GB 大约 20-30 分钟,视磁盘 IO 性能)。
7. 得到三个文件:WindowsServer2019.ovf、WindowsServer2019-disk1.vmdk(系统盘)、WindowsServer2019-disk2.vmdk(数据盘)。

阶段 2:格式转换(预计 30 分钟)

1. 把 OVF 文件夹拷贝到一台有 qemu-img 的 Windows 工作站。
2. 打开 PowerShell,执行转换:

   C:\qemu\qemu-img.exe convert -f vmdk -O vhdx -o subformat=fixed `
     "D:\convert\WindowsServer2019-disk1.vmdk" `
     "D:\convert\WindowsServer2019-disk1.vhdx"

3. 系统盘固定大小很重要,SQL Server IO 性能不受影响。
4. 数据盘用动态扩展:

   C:\qemu\qemu-img.exe convert -f vmdk -O vhdx -o subformat=dynamic `
     "D:\convert\WindowsServer2019-disk2.vmdk" `
     "D:\convert\WindowsServer2019-disk2.vhdx"

5. 两个 VHDX 文件上传到 Hyper-V 主机的 VHD 目录(如 D:\Hyper-V\VMs\WindowsServer2019\)。

阶段 3:Hyper-V 端配置(预计 20 分钟)

1. Hyper-V 管理器 → 新建虚拟机:
   • 名称:WindowsServer2019
   • 代数:Gen 1(原 VM 是 BIOS)
   • 内存:8192 MB(动态内存启用,最小 4096 MB)
   • 网络:接原 VLAN 的虚拟交换机
   • 虚拟硬盘:稍后连接
2. 设置 → IDE Controller 0 → 硬盘驱动器 → 浏览 → 选 disk1.vhdx 作为系统盘。
3. 设置 → IDE Controller 1 → 添加硬盘 → 选 disk2.vhdx 作为数据盘。
4. 启动 VM。

阶段 4:首次启动修复(预计 15 分钟)

1. VM 启动后第一次会蓝屏 0x7B(预期内),强制关机。
2. 设置 → SCSI Controller → 移除磁盘,改用 IDE 控制器挂载(BIOS VM 启动必须 IDE)。
3. 再次启动,这次能进系统,但网络不通。
4. 设备管理器 → 卸载 “VMware VMCI Device” 和 “VMware Accelerated AMD PCNet Adapter”(如果还残留)。
5. 设置 → 卸载 “VMware Tools”(如果有装)。
6. 重启,Windows 自动加载 Hyper-V 网络驱动,网络恢复。
7. IP 配置核对(应该是 DHCP 自动获取,或原静态 IP)。

阶段 5:验证(预计 15 分钟)

1. 从外部机器 ping VM 的 IP,确认网络通。
2. 远程桌面连入 VM,确认业务正常运行。
3. 检查 SQL Server 服务状态、IIS 应用池是否正常。
4. 检查数据盘文件是否完整(比对原文件数和大小)。

阶段 6:原 VM 清理(预计 10 分钟)

1. 确认 Hyper-V 上的 VM 稳定运行 24-48 小时后,删除 ESXi 上的原 VM。
2. 删除 OVF/VMDK 临时文件。
3. 更新 IP 地址管理表(DHCP 保留、AD 记录、监控配置等)。

总耗时:约 2 小时(包含等待时间)。实际迁移窗口 30-45 分钟足够,其他时间是 IO 等待和验证。

七、Linux 虚拟机迁移差异

Linux VM 迁移比 Windows 简单得多,因为 Linux 内核几乎所有主流虚拟硬件驱动都内置了。

7.1 Linux 迁移的特殊优势

• 无需装驱动:Linux 内核从 3.x 开始就内置了 Hyper-V 的 virtio、netvsc、storvsc 等驱动,迁移后重启即可识别。
• 无需卸载 VMware Tools:open-vm-tools 是用户态工具,卸载与否不影响启动,只是会浪费一点磁盘空间。
• 文件系统透明:EXT4、XFS、Btrfs 等都跨虚拟化平台兼容。

7.2 Linux 迁移的几个坑

• 引导加载器:如果原 VM 用 EFI 启动,转换 VMDK 后必须用 Hyper-V Gen 2,且启动模式选 EFI。如果用 MBR 启动,Gen 1 即可。判断方法:看 /etc/fstab 的挂载点和 lsblk -f 看分区类型。
• 网络配置重写:CentOS/RHEL 用 /etc/sysconfig/network-scripts/ifcfg-eth0 配置文件,VMware 网卡 MAC 变了,新网络接口名可能也不同(eth0 → eth1 或 hv_netvsc0)。建议迁移后用 ip link show 确认接口名,修改对应配置文件。
• initramfs 更新:如果原 VM 用 PVSCSI 等特殊控制器,内核启动时找不到磁盘。修法:在 ESXi 端先添加标准 LSI Logic 控制器和一个小启动盘(可以单独转),或者用 Hyper-V 的”安全模式”让 initramfs 自动重生成。

7.3 Linux 迁移建议命令

# 在 ESXi 端,如果是 EFI 启动的 VM,确认 firmware 类型
vim-cmd vmsvc/get.config <vmid> | grep -i firmware

# 在 Linux VM 内查看当前硬件信息
lspci | grep -i net    # 查看网卡
lspci | grep -i scsi   # 查看存储控制器
dmidecode -s bios-version  # 查看 BIOS 还是 UEFI

# 迁移后重置网络(以 CentOS 7 为例)
nmcli connection show     # 查看网络连接
nmcli connection delete uuid  # 删除旧连接
nmcli connection add con-name eth0 ifname eth0 type ethernet
nmcli connection modify eth0 ipv4.addresses 192.168.10.50/24
nmcli connection up eth0

八、Gen1 vs Gen2 虚拟机的选择

Hyper-V 的 Gen1 和 Gen2 是两种虚拟硬件代际,差异显著,选错会导致启动失败。

特性	Gen 1(传统)	Gen 2(现代)
启动模式	BIOS + MBR	UEFI + GPT
最大内存	1TB	12TB(Windows Server 2022)
最大虚拟 CPU	64	240
安全启动	不支持	支持
磁盘控制器	IDE(启动)	SCSI(启动)
PXE 启动	传统 PXE	标准 PXE
适用场景	老 OS(Win7、Win Server 2008)、BIOS VM	新 OS(Win10/11、Win Server 2012+)、Linux 现代版

选择原则:从 ESXi 迁移过来的 VM,看原 VM 是 BIOS 还是 UEFI,选对应代际。可以在 ESXi 端用 vim-cmd vmsvc/get.config <vmid> 看 firmware 字段:

• firmware = "bios" → Hyper-V 选 Gen 1
• firmware = "efi" → Hyper-V 选 Gen 2

九、常见故障与避坑指南

把高频故障汇总一下,出问题先查这里。

9.1 启动类故障

坑 1:启动报 “No UEFI-compatible file system was found”。
原因:选了 Gen 2 但磁盘是 MBR。
修法:VM 设置 → 固件 → 启动顺序选对;或者新建 Gen 1 VM。

坑 2:启动后无限重启,Windows Boot Manager 蓝屏。
原因:BCDBoot 配置损坏,或磁盘控制器类型错误。
修法:用 Windows 安装 ISO 启动,进入恢复模式执行 bootrec /rebuildbcd。

坑 3:Linux VM 启动后卡在 GRUB rescue。
原因:磁盘路径变了(如从 /dev/sda 变成 /dev/vda),GRUB 找不到。
修法:从救援模式启动,执行 grub-install /dev/sda 重新安装。

9.2 网络类故障

坑 4:Windows VM 能连网但无法访问外网。
原因:Hyper-V 虚拟交换机配置错误,或网关不通。
修法:检查 Hyper-V 虚拟交换机是否绑对外网卡,VM 网卡是否绑到正确交换机。

坑 5:Linux VM 启动后网卡名变了,IP 配置失效。
原因:MAC 地址变了,udev 规则改了网卡名。
修法:禁用 udev 持久化命名规则(/etc/default/grub 加 net.ifnames=0 biosdevname=0)或更新网络配置。

9.3 性能类问题

坑 6:迁移后 SQL Server 性能下降 30%。
原因:VHDX 是动态扩展格式,碎片严重。
修法:转固定大小 VHDX;启用 Hyper-V 的 VHDX 块大小优化(Set-VHD -Path xxx.vhdx -BlockSizeBytes 64MB)。

坑 7:Hyper-V 主机 CPU 占用高。
原因:动态迁移或启用了嵌套虚拟化。
修法:关闭不必要的功能,合理分配 CPU 资源。

十、方案对比与最佳实践

最后,横向对比一下不同迁移方案,以及整理一份操作 checklist。

10.1 主流迁移方案对比

方案	操作复杂度	成功率	停机时间
OVF 导出 + qemu-img 转换	中等	高	30-60 分钟
VMDK 直拷 + StarWind 转换	低	高	30-45 分钟
vCenter Converter Standalone	低	中	较长
Microsoft MVMC(免费版已停更)	高	中	较长
第三方商业工具(Veeam、Zerto)	低	高	15-30 分钟

10.2 最佳实践清单

• 先备份再迁移:即使源 VM 在 ESXi 上有快照,迁移前再做一次完整备份。迁移是 IO 重操作,出问题能回滚。
• 先小后大:先拿一台不重要的 VM 跑通流程,再批量迁移生产 VM。
• 记录原 VM 配置:迁移前用 vim-cmd vmsvc/get.config 把原 VM 的 CPU、内存、网卡、磁盘配置记录下来,Hyper-V 端照着配。
• 分阶段验证:每迁移一台 VM,先让它在 Hyper-V 跑 24 小时,确认无问题再批量推。
• DNS/IP 同步更新:迁移后立即更新 DHCP 保留、AD 记录、DNS 反向解析,避免 IP 冲突。
• 保留原 VM 一周:迁移完成后保留 ESXi 上原 VM 一周(关闭状态,不删除),作为应急回滚备份。

10.3 写在最后

ESXi 迁移到 Hyper-V 这事,在网上搜出来的教程大多是五六年前的,工具链、界面都已经迭代了好几轮。最稳妥的做法是按本文流程先小后大、先测后生产——一台 VM 完整跑通后,后面 50 台都是复制粘贴的工作量。涉及关键业务 VM 的迁移,强烈建议在测试环境完整模拟一遍,把所有坑踩过一遍,再上生产。