先说明我的场景：我在 Windows 上用了很长时间 VMware Workstation，里面跑着 Ubuntu 22.04 开发环境和一台 Windows 10 测试机，后来换了 Mac，又不想重新装一遍系统、配一遍环境，所以想办法把 VMware 的虚拟机整体迁到 Parallels Desktop 里。折腾下来发现新版 Parallels 的迁移流程和网上那些老教程差别不小，有些操作步骤已经变了，有些坑是老的教程完全没提到过的。
这篇内容主要面向三类人：一类是我这种从 VMware 换到 Parallels 的迁移用户，一类是电脑上同时装了 VMware 和 Parallels、想统一虚拟化平台的用户，还有一类是准备从 Windows 换 Mac、但舍不得旧虚拟机里环境的人。我会把迁移原理、三种常用迁移方式的取舍、完整的实操步骤、以及我踩过的坑都整理出来，尽量做到照着操作就能把虚拟机成功搬过去。
1. 写在前面的核心问题：VMware 和 Parallels 的虚拟机到底差在哪
1.1 两种虚拟磁盘格式的底层差异
VMware 的虚拟机磁盘文件是.vmdk，Parallels 的虚拟磁盘是.hdd（实际上内部是.pvs格式），这两种格式本身都是对虚拟机磁盘的封装，但内部的组织方式、元数据结构、快照机制都不一样。
你可能觉得虚拟磁盘不就是一个大文件吗，直接复制过来不就行了？实际上没那么简单。VMware 的.vmdk文件可能是单文件，也可能是拆分成多个 2GB 小文件（split），而且里面记录了磁盘的几何参数、描述信息，快照也会产生额外的描述文件。Parallels 直接读取 VMDK 的能力有限，尤其是涉及快照链的时候，它经常只认最基础的 flat 格式。
还有一个关键区别：虚拟机的“外壳”不同。VMware 用.vmx文件描述虚拟机配置（内存、CPU、网卡类型、磁盘控制器），Parallels 用.pvm文件夹来管理，里面包含了 config.pvs 和磁盘镜像。迁移的本质就是两件事：把磁盘格式转换过来、把虚拟硬件配置重新生成一遍。
1.2 新版 Parallels 的导入逻辑有了明显变化
老版本的 Parallels Desktop 有一个叫 Parallels Transporter 的迁移工具，可以跨电脑迁移 VMware Workstation 虚拟机。到了新版本（我默认按 Parallels Desktop 19、20 这一代说），导入逻辑变成这样：你直接在 Finder 里双击.vmwarevm文件夹或者.vmdk文件，Parallels 会弹窗询问要不要转换导入，或者通过菜单“文件 → 打开”来触发导入流程。
但这里有个坑：新版本对 Windows 虚拟机的检测更严格，如果你虚拟机磁盘格式比较老、或者动过默认的虚拟硬件配置，双击导入大概率会失败，提示格式不支持或读不到磁盘。这不是说你操作错了，而是 Parallels 对 VMDK 的支持范围有限。后面我会给出一条更稳的路径。
1.3 迁移前必须做的三项准备工作
不要拿系统当前正在运行的虚拟机直接迁移，一定要先做这三件事。
第一，完整关机，不是挂起。挂起状态会有内存快照（.vmem文件），这种状态下迁移经常会出现导入到一半报错，或者迁移完启动后系统状态“假死”。把虚拟机关机，等彻底断电。
第二，删掉不需要的快照。VMware 的快照会产生一组增量磁盘文件，Parallels 转换时大概率会漏掉或者读错链。我的建议是在 VMware 里把有价值的快照合并，或者直接删掉所有快照，留下一个干净的、扁平化的磁盘映像。如果你需要保留快照，那就别用 Parallels 的导入向导，用后面说的 OVF 方式。
第三，虚拟机里清理临时文件。Windows 虚拟机做一次磁盘清理和碎片整理，Linux 虚拟机清一下 apt 缓存。这个步骤不是为了省那点空间，是为了减少后续磁盘转换的时间，也让转换出来的镜像更“健康”。
另外强烈建议在 VMware 里记录下当前虚拟机的关键配置：内存多大、几个 CPU 核、磁盘控制器类型（IDE/SATA/NVMe）、网卡类型（e1000/vmxnet3）。后面在 Parallels 里重新配置时，这些参数有参考价值。
2. 三条迁移路线的对比与选型
2.1 路线一：Parallels 直接导入 VMDK
操作上很简单：在 Parallels Desktop 里菜单栏选“文件 → 打开”，定位到 VMware 虚拟机的.vmwarevm文件夹里的.vmdk文件，Parallels 会识别到这是个 VMware 磁盘，然后开始转换。
这个方式适合什么情况？你的 VMware 虚拟机磁盘格式是单文件 VMDK、没有快照、Guest 系统是主流 Linux 发行版或 Windows 10/11，这种情况下成功率比较高。Parallels 会生成一个新的.pvm文件夹，磁盘格式转换成自己的.hdd。
缺点也很明显：如果 VMDK 是 split 形式（多文件），Parallels 经常识别成损坏磁盘；如果虚拟机里有多个磁盘（比如数据盘、系统盘分开），它可能只导入其中一个；如果磁盘控制器用的 NVMe，转换后 Windows 可能出现启动失败的蓝屏。
2.2 路线二：从 VMware 导出 OVF/OVA 再导入
这是我在实践中觉得最稳的一条路线。VMware Workstation 的“文件 → 导出为 OVF”功能，可以把整个虚拟机打包成一个标准化的 OVF 描述文件加若干 VMDK 磁盘，Parallels 对 OVF 格式的兼容性明显比对裸 VMDK 好。
导出的时候注意：VMware 会让你选择 OVF 还是 OVA。OVF 是一堆文件，OVA 是单个压缩包。我建议选 OVF，因为 OVA 是 tar 打包，Parallels 导入时还要解包，中间多一步出错概率就高一点。导出完成后，在 Parallels 用“文件 → 打开”，选择.ovf文件，它会识别成可导入的虚拟机。
这个方案的优势是：OVF 是跨平台标准，Parallels 对它支持得最好；快照会被扁平化，不用担心快照链问题；虚拟硬件描述完整，Parallels 能准确还原 CPU 和内存配置。缺点就是导出导入时间比较长，大磁盘可能要等很久。
2.3 路线三：手动复制 VMDK，然后用 qemu-img 转换
如果你的 VMDK 文件 Parallels 不认、OVF 导出又失败，那就只能用命令行方案了。先装一个 Homebrew，然后安装 qemu 工具，用qemu-img把 VMDK 转成 Parallels 能认的 RAW 或者 qcow2 格式。
转换命令大概是：
brew install qemu qemu-img convert -f vmdk -O raw source.vmdk disk.raw然后把 raw 文件复制到新建的 Parallels 虚拟机目录里，改名为disk.hdd，让 Parallels 当作自己的磁盘来启动。这个做法比较折腾，但基本能解决所有格式不识别的问题。
我自己的建议是：普通人优先走路线二（OVF），如果导出不了再走路线一，路线三适合已经有一些 Linux 命令行基础、不介意手动操作细节的用户。三条路线我都实际跑过，下面用一张表直观对比一下：
| 对比项 | 直接导入 VMDK | 导出 OVF 再导入 | qemu-img 手动转换 |
|---|---|---|---|
| 操作难度 | 低 | 中 | 高 |
| 成功率（新版 PD） | 中等 | 较高 | 高 |
| 对快照支持 | 不好 | 自动扁平化 | 需手动合并 |
| 多磁盘支持 | 可能丢失 | 完整保留 | 需逐个转换 |
| 适合人群 | 图省事的新手 | 大多数用户 | 遇到问题的进阶用户 |
2.4 选择迁移方式时还应该考虑什么
除了格式兼容性，还要考虑迁移后系统的可维护性。如果你原来的 VMware 虚拟机里装了很多开发环境，建议迁移后别直接删掉原来的 VMware 虚拟机文件，至少保留两周。我就是迁移完第三天发现 Parallels 那边某个容器服务怎么都起不来，最后回到旧的 VMware 环境对比排查，才找到是虚拟网卡 MAC 地址变化导致的问题。
另外还要考虑磁盘空间。Parallels 转换过程中会创建一个新镜像，磁盘占用会短暂变成“原镜像大小 + 新镜像大小”。如果你的硬盘只有 50GB 空闲，但虚拟机占 40GB，那先清理磁盘空间再做转换，否则转换到一半会提示磁盘不足。
3. 实操记录：Ubuntu 22.04 和 Windows 10 完整迁移过程
这一节我拿两台虚拟机来实际操作，一台 Linux、一台 Windows，操作系统不同，迁移后要处理的问题完全不一样。
3.1 实操前的环境清单
我迁移用的环境是这样的：
- 源平台：Windows 11 上的 VMware Workstation 17
- 虚拟机 A：Ubuntu 22.04 LTS，40GB 磁盘，2 核 4GB 内存，网卡 e1000
- 虚拟机 B：Windows 10 Pro 22H2，60GB 磁盘，4 核 8GB 内存，网卡 vmxnet3
- 目标平台：MacBook Pro（Apple Silicon）上的 Parallels Desktop 20
- 路径规划：外部移动硬盘上有 200GB 空闲，用作过渡
如果你用的 Windows 虚拟机是 Arm 版本的，思路一样，但驱动细节会有差异。
3.2 Ubuntu 22.04 迁移全过程
我在 VMware 里将虚拟机 A 完整关机，然后执行“文件 → 导出为 OVF”。导出过程大约耗时 15 分钟，生成一个.ovf文件和一个对应的.vmdk文件。
接着在 Mac 上打开 Parallels Desktop，选择“文件 → 打开”，定位到那个.ovf文件。Parallels 会显示一个导入预览界面，让我确认虚拟机的名称、存放位置，以及分配多少 CPU 和内存。这里我注意到的变化是：新版 Parallels 在 Apple Silicon 上默认还会让你选系统版本，它会自动匹配最佳的虚拟硬件配置。
点击“导入”后就开始转换了。整个转换过程大概 12 分钟，期间虚拟磁盘从 VMDK 转成了 PVS 格式。导入完成后我直接点击启动，但第一次启动就翻车了，卡在一个奇怪的界面，没有进入 GRUB。
排查下来，问题是这样的：VMware 导出 OVF 时，磁盘控制器写的是默认的 SATA 控制器，但 Parallels 导入后识别成了 SCSI 控制器，而 Ubuntu 22.04 默认的内核没有包含对应的 SCSI 驱动。解决办法也不难：在 Parallels 虚拟机配置里，把磁盘控制器手动改成 SATA，再启动就能进系统。
进系统后又遇到第二个问题：网络不通。我用ip a看了一下，发现原来 VMware 里的ens33网卡没了，变成了eth0没被 DHCP 配置。这就是典型的迁移后网上方识别问题，后面我会详细写怎么处理。
3.3 Windows 10 迁移全过程
Windows 这台我更谨慎，用了 OVF 导出方案。导出耗时接近 30 分钟（磁盘有 60GB），Parallels 导入又用掉 20 多分钟。导入完成后第一次启动，Windows 直接蓝屏，错误代码是0x0000007B，也就是无法访问启动设备。这个错误在跨虚拟化平台迁移 Windows 时太常见了，本质是原来的存储控制器驱动没了。
解决办法是迁移前在 Windows 虚拟机里手动注入通用驱动。我用的方法是：在 VMware 虚拟机里打开设备管理器，找到 IDE/ACHI 控制器（或者 SCSI 控制器），右键选择“更新驱动程序 → 从计算机选择”，然后选择“标准 NVM Express 控制器”或“标准 SATA AHCI 控制器”，提前把微软通用驱动装好。做完这个操作后再导出 OVF，迁移成功率会高很多。
不过我已经踩了一次坑，所以补救方式是：在 Parallels 里开机时按 F8 进入 Windows 恢复模式（实际上 Parallels 会先弹一个启动设备选择菜单），选择安全模式启动，然后在安全模式下手动把驱动切回标准控制器。这个操作能用，但是比较痛苦，所以还是建议在 VMware 里提前做。
Windows 10 迁移成功后，最重要的一步是安装 Parallels Tools。Parallels 会在首次启动时自动提醒安装，或者通过菜单“操作 → 安装 Parallels Tools”。装完后重启，分辨率自动适配、剪贴板共享、文件拖拽、共享文件夹这些功能就都正常了。
3.4 迁移后必须处理的三项配置
不管 Linux 还是 Windows，迁移完都建议检查这三项配置。
第一，分辨率。Parallels 装了 Tools 或者prl-tools之后，自适应分辨率才正常。如果发现分辨率只能固定在 1024x768，说明 Tools 没装好，或者显示驱动被禁用了。
第二，共享文件夹。Parallels 的共享文件夹功能，在虚拟机里默认映射到/media/psf（Linux）或者网络位置（Windows）。如果迁移后共享文件夹没出现，需要在虚拟机配置里重新设置 macOS 路径与虚拟机内路径的映射。
第三，外设映射。比如 USB 设备、摄像头、打印机，迁移后需要重新确认是否授权给这台虚拟机。Parallels 默认在第一次插入设备时弹窗询问，别把它当成弹窗广告点掉。
4. 常见问题与排查技巧实录
4.1 导入时提示“无法检测磁盘格式”
这个提示我遇到不止一次，尤其是在直接双击.vmdk文件的时候。多半原因是 VMDK 是 split 模式（磁盘拆成了多个文件）或者带有快照。解决思路很简单：不要直接双击，先在 VMware 里用“文件 → 导出为 OVF”，导出过程会合并快照、扁平分片，然后再导入到 Parallels。
如果你真的无法进入 VMware 去导出了，还可以在 VMware 里用vmware-vdiskmanager工具合并分片：
vmware-vdiskmanager -r source.vmdk -t 0 merged.vmdk-t 0表示输出成单文件、预分配的 flat 格式，这种格式 Parallels 的识别率最高。
4.2 Linux 迁移后没有网络
新版 Ubuntu 默认用 Netplan 管理网络，你在 VMware 里看到的网卡名是ens33或ens160，迁移到 Parallels 后网卡变成了eth0或enp0s5，原来的配置文件自然就失效了，DHCP 根本不会去尝试配置新网卡。
处理方法：编辑/etc/netplan下的 YAML 配置文件，确认里面用的是 DHCP（大多数桌面版默认就是），然后把网卡名称改成新环境里的名称。如果你不想纠结名称变化，直接在 GRUB 内核参数里加net.ifnames=0 biosdevname=0，强制 Linux 使用eth0这种传统命名，配置文件就稳定了。
4.3 Linux 迁移后图形界面异常
有一些 Ubuntu 用户迁移后卡在登录界面循环、或者进桌面后很卡，大概率是显卡驱动冲突。VMware 虚拟机的显卡是 VMware SVGA，Parallels 用的是自己的显示适配器，迁移后如果不卸载旧的 VMware 驱动，容易出问题。
处理建议：在虚拟机里卸载open-vm-tools和 vmware 显卡驱动，然后重新安装 Parallels Tools。Parallels Tools 在 Linux 下是一个 ISO，挂载后执行install.sh，它会自动处理显卡模块和内核模块编译。Apple Silicon 机器上，如果你迁移的是 x86_64 架构的 Ubuntu，只能通过模拟运行，图形性能会弱一些，但一般开发环境够用了。
4.4 Windows 迁移后系统激活失效
这个是很多人没预料到的。Windows 10 的数字许可证和硬件绑定度比较高，虚拟机跨平台后，主板、硬盘、网卡的虚拟硬件全变了，Windows 可能会提示激活出现问题。
解决的思路是：如果你有微软账户，登录后绑定数字许可证，理论上会自动重新激活；如果激活失败，可以尝试在设置里“更改产品密钥”并重新输入同一个密钥；如果都不行，联系微软客服走人工激活流程。这里注意，用破解激活工具是绝对不建议的，风险远大于收益。我在实操中遇到的情况比较顺利，微软账户自动激活就恢复了，没有走人工流程。
4.5 Parallels 网络初始化失败
Parallels Desktop 偶尔会在启动虚拟机时提示“网络初始化失败”，这个在 Parallels Desktop 16 时代出现的频率更高。新版 19/20 偶尔也会遇到。
常见的诱因有三个：macOS 的防火墙或安全软件拦截了 Parallels 的网络进程；虚拟网卡配置损坏；DHCP 服务异常。修复顺序建议：先重启 Mac 上 Parallels 的虚拟网络服务，通过终端执行：
sudo /Applications/Parallels\ Desktop.app/Contents/MacOS/prl_naptd restart然后检查“系统设置 → 网络”里 Parallels 的虚拟网卡是否被禁用，如果禁用就重新启用。还不行的话，在 Parallels 菜单里“文件 → 虚拟机列表 → 选择出问题的虚拟机 → 配置 → 硬件 → 网络”，把网络类型从“共享网络”切到“桥接网络”，启动一次再切回来，很多时候这个操作就能把事情“拧”好。
4.6 Apple Silicon 和 Intel Mac 的差异要注意
新版 Parallels 在 Apple Silicon Mac 上运行的是 ARM 架构的虚拟机，迁移方式会有区别。如果你的 VMware 虚拟机是 x86 架构的 Ubuntu/Windows，在 Apple Silicon 上导入时，Parallels 会提示“是否使用模拟运行模式”，性能上会打折扣。如果你打算长期使用，建议直接在 Apple Silicon 上新建 ARM 版本虚拟机，重新安装系统，性能会好很多。
Intel Mac 上则没有这个问题，因为 Intel Mac 本来就是 x86 架构，迁移后的虚拟机可以直接跑，性能损失很小。我自己的主力机现在是 Apple Silicon，所以在上面跑 x86 的 Ubuntu 虚拟机时，明显感觉到编译速度比在 VMware 里慢，评估之后决定直接在 Parallels 里建了一个 ARM 版的 Ubuntu，日常开发体验反而更好。
5. 迁移后的性能调优与长期维护经验
5.1 CPU 和内存分配要重新评估，不要照搬旧配置
VMware 虚拟机里的 CPU 和内存配置，是 Windows 宿主机当时资源的快照。换了 Parallels 之后，Mac 的资源变化很大，尤其是 Apple Silicon 统一内存架构下，内存分配别直接照抄原来的“4GB”或者“8GB”。
我个人的建议是：在 Parallels 设置里把内存分配到 Mac 总内存的 1/4 到 1/3，CPU 核心数不要超过 Mac 实际物理核心的一半。给太多资源反而会拖慢宿主机，而且虚拟机的性能提升并不线性。比如我的 Mac 是 16GB 内存，Ubuntu 虚拟机分 4GB，Windows 测试机分 4GB，剩下的留给 macOS 自己用，整体体验就很流畅。
5.2 磁盘瘦身：迁移后镜像可能比你想象中大
Parallels 转换后的磁盘默认是精简分配（也就是按需增长），但如果你从 VMware 迁移过来的磁盘是固定大小预分配的，转换后它可能保持固定大小，白白占掉很多空间。
在 Parallels 里可以这样瘦身：虚拟机配置里找到硬盘，点击“压缩”，Parallels 会自动回收未使用的空间。Linux 虚拟机在压缩前最好执行一下：
sudo fstrim -v /Windows 虚拟机则先做一次“优化并碎片整理驱动器”，再执行压缩。这个操作能省下的空间看虚拟机里占用的实际数据量，我曾经把一个 80GB 的 Windows 测试机压缩到 30GB，效果非常明显。
5.3 备份和快照策略
Parallels 的快照机制和 VMware 不太一样，Parallels 的“时间线”功能会自动间隔截图，这功能看着方便，但其实会不断占用磁盘空间。如果你迁移后不需要频繁回滚，建议关闭自动快照，改成手动快照。
备份虚拟机最省事的办法是直接找到~/Parallels/虚拟机名称.pvm文件夹，右击选择“压缩”，然后再复制到移动硬盘。因为.pvm是一个自包含的文件夹，拷贝到另一台 Mac 上，双击就能用 Parallels 打开，不需要额外导入。我自己就把 Ubuntu 的 pvm 打包到了移动硬盘，换电脑时直接拷过去，干净利落。
5.4 迁移完成后的最后一步：验证环境完整性
这一步很多人会忽略。迁移完成后别急着删旧环境，先把日常开发流程完整过一遍：数据库能不能连上、IDE 能不能打开、编译工具链能不能正常工作、定时任务是否还在正确触发。我用了一个检查清单，你可以参考：
- 检查系统时间是否同步（虚拟化平台迁移后最常见的时间漂移问题）
- 检查主机名和 IP 是否按预期解析
- 检查 SSH 密钥和 Git 配置是否完整
- 检查 Docker/容器服务的网络模式是否正常
- 检查所有数据盘是否都挂载成功
- 检查 Windows 虚拟机里的 D 盘（数据盘）是否正常显示
如果验证过程中发现某些服务异常，不要慌，先对照我在第 4 节提到的问题排查，大多数迁移后的异常点都能找到原因。
我在实际迁移中踩过的最大一个坑，是在迁移 Windows 虚拟机后忽略了时区同步，导致微软账户登录一直失败。查了很久才发现是系统时间和真实时间差了 8 小时，修好后一切正常。这类细节往往比迁移过程本身更耽误时间，所以还是建议你拿到迁移后的虚拟机后，第一时间把系统时间、时区、同步服务确认好，再往下做别的配置。
