外观
从 ESXi 迁移一批虚拟机
Broadcom 收购 VMware 后的授权变化，让不少人开始把 ESXi 虚拟机搬到 Proxmox VE。PVE 9.x 提供的 ESXi 导入向导（ESXi Import Wizard）能直连 ESXi 主机批量读取虚拟机并转换配置，是官方目前首推的方法。这篇讲的是一批虚拟机该按什么顺序迁移，具体每一步的界面操作见导入虚拟机。
方案总览
| 阶段 | 目标 | 关键决策点 |
|---|---|---|
| 迁移前 | 记录网络配置、卸载 VMware Tools、规划停机窗口 | 这批虚拟机能不能接受停机迁移，还是要用 Live-Import |
| 建立连接 | 在 PVE 里添加 ESXi 存储源 | 直连 ESXi 主机而不是走 vCenter（性能差很多） |
| 批量导入 | 逐台或分批导入 | 同时导入的磁盘不建议超过 4 块，避免宿主机内存吃紧 |
| 收尾 | 装 VirtIO 驱动、装 QEMU Guest Agent、切换总线类型 | Windows 客户机不能直接切到 VirtIO SCSI 启动 |
| 验证与保留期 | 验证业务正常后再关闭源虚拟机 | 保留 ESXi 侧虚拟机到确认迁移成功为止 |
导入向导不是唯一方法
如果虚拟机的磁盘在 vSAN 上、或者只有个别几台要迁移，qm disk import 手动导入单块磁盘、或者先用 ovftool 导出再 qm importovf，也是官方文档列出的路径，细节见导入虚拟机。这篇聚焦向导批量迁移这一条主线。
需要用到的章节
迁移本身
- 导入虚拟机：ESXi 导入向导、OVA/OVF 与导入磁盘
- ESXi 与 PVE 概念对照（存储、网络、快照等术语怎么对应）
迁移后必做
- VirtIO 驱动与 QEMU Guest Agent
- CPU 类型、自定义 CPU 模型与嵌套虚拟化（源集群 CPU 型号不一致时怎么选目标 CPU 类型）
承接迁移过来的虚拟机
验证与回退
实施顺序
- 盘点：列出全部待迁移虚拟机，记录操作系统版本、磁盘大小、是否有快照（带快照的虚拟机导入明显更慢）、网络配置（尤其是 Windows 的静态 IP 和 DHCP 保留的 MAC 绑定）。
- 迁移前清理：在源虚拟机里卸载 VMware Tools；能接受短暂停机的，提前装好 VirtIO 驱动并确认已打进 initramfs（Linux）。
- 搭桥：在 PVE 的存储配置里添加指向 ESXi 主机（不是 vCenter）的 ESXi 存储源，自签名证书环境按向导处理证书信任。
- 小规模试跑：先挑 1～2 台非关键虚拟机跑一遍完整流程，确认目标存储、网桥映射、启动方式都符合预期，再批量处理其余虚拟机。
- 分批批量导入：按官方建议控制并发（单批导入磁盘不超过 4 块），关闭源虚拟机后再导入，避免同一台虚拟机两端同时运行。
- 逐台收尾：装 QEMU Guest Agent，按需切换磁盘总线到 VirtIO SCSI（Windows 需要先在 IDE/SATA 下装好驱动再切换），确认网络配置随硬件变化后依然正确。
- 验证期：业务方确认功能正常后，再关闭并保留 ESXi 侧虚拟机一段时间，不要立即删除。
风险评估
单点故障
批量导入依赖 ESXi 主机在迁移期间保持可用且响应及时——ESXi 的管理接口（hostd）对并发连接数有限制，导入过程中如果触发限流，一批任务会同时报错，不是单台虚拟机的问题。迁移窗口内避免在源侧做其他重负载操作（备份、克隆），减少触发限流的概率。
同一故障域
导入完成后如果立即删除源端虚拟机，一旦目标端配置有遗漏（网络没接对、启动盘没设对、Guest Agent 没装），就没有回退的余地。导入不等于验证完成，源虚拟机和目标虚拟机在验证期内是唯一的数据副本来源，此时它们互为对方的回退手段，直到确认迁移成功前都不能同时销毁或同时开机。
同一台虚拟机不能两端同时开机
如果源 ESXi 虚拟机和刚导入的 PVE 虚拟机使用同一份磁盘（例如挂载磁盘后直接迁移存储的做法），两边绝不能同时启动，否则磁盘会被两边同时写入而损坏。影响范围：该虚拟机的全部数据。前置条件：确认源虚拟机已关机且不会被自动唤醒（检查 vCenter 计划任务、DRS 规则）。回退：导入前用配置备份任务对目标虚拟机做一次基线备份，出问题时可以回滚到导入完成的初始状态，而不是依赖还在运行的源虚拟机。
验收清单
- [ ] 目标虚拟机能正常开机、关机，
qm status <vmid>显示running - [ ] QEMU Guest Agent 已安装，Summary 页能看到 IP 地址
- [ ] 磁盘总线、网卡型号符合VirtIO 驱动与 QEMU Guest Agent里的建议，或明确记录了暂不能切换的原因
- [ ] 客户机内部网络配置（静态 IP、路由、DNS）迁移后依然正确
- [ ] 业务功能经过实际验证，不只是「能开机」
- [ ] 迁移完成后做过一次备份，而不是依赖仍然保留的源虚拟机作为唯一副本
- [ ] 源端 ESXi 虚拟机已关机保留，等验证期结束再清理
常见问题
导入过程中报 503 Service Unavailable。 通常是 ESXi 主机的并发会话数限制触发，等待约 30 秒后重试，或分批减少并发数量；官方文档给出了调整 ESXi 端会话限制的参数，具体版本对应关系请对照官方 wiki 核实。
导入后虚拟机启动不了。 先尝试用 SeaBIOS/OVMF 的救援启动项，它通常带有更全的驱动；启动不了再把磁盘总线临时切回 IDE/SATA，确认能进系统后再逐步切换到 VirtIO，见VirtIO 驱动与 QEMU Guest Agent。
Windows 虚拟机迁移后网络配置错乱。 迁移后网卡通常会被识别为新硬件，Windows 上如果原来配置了静态 IP，建议迁移前先改成自动获取，迁移后再手动配置，避免残留的静态配置和新网卡冲突。
虚拟机带快照，导入特别慢。 官方文档确认带快照的虚拟机导入会明显变慢，条件允许的话先在 ESXi 侧合并快照再迁移。
参考资料
- Migrate to Proxmox VE（官方 wiki）
- Proxmox VE 管理指南：虚拟机导入相关章节，https://pve.proxmox.com/pve-docs/
- 导入虚拟机
- ESXi 与 PVE 概念对照