第一次在 Windows 上用 VMware 装 macOS 虚拟机的人,几乎都会卡在同一个画面:新建虚拟机向导一路点下去,操作系统列表里从 Ubuntu 翻到 FreeBSD,就是找不到 Apple 相关的条目。这个现象本身就说明了整件事的性质——它不是点几下“下一步”就能完事的流程,而是一次需要提前铺路的系统工程。你面对的不是一个软件问题,而是一串环环相扣的环境问题:宿主机的虚拟化权限被谁占着、VMware 的客户机列表被谁解锁、镜像格式对不对、vmx 配置里少没少关键行。
这篇内容面向的是手上有台性能还行的 Windows 机器、想弄一套 macOS 环境做开发调试或软件兼容性测试的人。不论是第一次接触 VMware 虚拟机的新手,还是装过 Linux 虚拟机、这次想跨到 macOS 的老手,都能从中找到可以直接照做的东西:从硬件门槛的评估、宿主机 Hyper-V 的清理、解锁补丁的执行、vmx 文件的手工补丁,到抹盘安装、Tools 安装、共享目录替代方案和一大串高频报错的定位链路。
需要先说明一句:本文内容面向软件兼容性测试与开发调试场景,请确保你的使用方式符合相关软件的使用条款。
1. 先算清楚账:虚拟机跑 macOS 到底吃多少硬件
1.1 什么样的人适合走虚拟机这条路
虚拟机方案的价值不在“替代真机”,而在于它把一套完整系统变成了一个文件夹。你可以随时打快照、随时回滚、随时复制出第二套环境做对比测试,而这些在真机或者“把系统直接装到裸机硬盘上”的方案里都很难做到。我见过最典型的几个使用场景:iOS 方向的前端或测试同学需要在接近真实的环境里验证页面渲染和 Safari 行为;做客户端软件的人需要确认自家程序在 macOS 上的安装包能否正常解锁、文件权限是否符合预期;做 UI 的人需要对着 macOS 的系统控件调字号和间距。
这些场景的共同点是:不需要 GPU 重度负载,不需要依赖真实硬件的传感器,只需要一套能跑起来、能装软件、能联网的系统。反之,如果你打算在虚拟机里跑视频剪辑、跑大型原生编译、玩依赖 Metal 的游戏,那基本可以放弃这条路,虚拟显卡的性能天花板很低,投入的时间和实际体验不成正比。触摸板手势、指纹识别、连续互通这类特性在虚拟机里也不可用,因为它们绑定了真实的硬件控制器。
还有一点值得先说清楚:虚拟机里的 macOS 性能大约相当于一台十年前的中端 Mac。日常办公、写代码、跑浏览器、装几个常用软件没问题,但把它当成主力生产环境用,一周之内你一定会想换方案。
1.2 CPU、内存、磁盘这三个硬指标
很多人装到一半失败,回头才发现是硬件压根不够,或者资源分配方式错了。下面这张表是我自己反复试过之后总结的一套分配参考,宿主机的物理核心数和内存是前提,右侧是给虚拟机的建议值。
| 宿主机配置 | 建议 vCPU | 建议内存 | 建议磁盘 | 实际体验 |
|---|---|---|---|---|
| 4 核 / 8GB / 机械盘 | 不建议 | — | — | 安装阶段就可能无限重启 |
| 4 核 / 8GB / SSD | 2 核 | 5GB | 80GB | 能装能用,操作有明显迟滞 |
| 6 核 / 16GB / SSD | 4 核 | 8GB | 100GB | 日常开发可接受,编译偏慢 |
| 8 核以上 / 32GB / NVMe | 4 到 6 核 | 12 到 16GB | 120GB | 接近一台入门级 Mac 的体验 |
这里有几个反直觉的点。vCPU 不是给得越多越快,VMware 的调度器需要把虚拟核心映射到物理核心上,如果你给虚拟机 8 个核心而宿主机总共只有 8 个,宿主机自己就没核心可用了,整个系统会陷入互相抢占。经验做法是 vCPU 不超过物理核心数的一半,并且尽量给偶数。内存同理,给虚拟机 8GB 而宿主机只剩 4GB,Windows 会开始大量使用页面文件,虚拟机的磁盘 IO 会被拖垮。
磁盘的坑更大。机械硬盘基本上宣告失败,因为 macOS 安装阶段会有大量小文件随机读写,机械盘的随机 IO 性能会让安装卡在“剩余 12 分钟”长达几个小时。哪怕宿主机用的是 SATA SSD,也建议把虚拟机文件放在系统盘以外的独立 SSD 分区上,避免和 Windows 的页面文件抢带宽。另外,虚拟机磁盘的容量不要卡着 60GB 给,macOS 系统本身加上 Xcode 这类开发工具很容易吃掉 40GB 以上,磁盘写满之后系统会出现各种莫名其妙的行为,给 100GB 起步比较稳妥。
顺带提一句 CPU 代际的问题。macOS 的新版本对 CPU 指令集要求逐年提高,2013 年之前的处理器(比如第三代酷睿)在跑 Monterey 之后的版本时会相当吃力,甚至直接无法引导。如果你手上是这类机器,务实的选择是把目标定在 Catalina 或者 Mojave,不要硬上新版本。
1.3 VMware 版本和解锁补丁之间的绑定关系
VMware Workstation 本身并不在你的客户机操作系统列表里放 Apple 的条目,这是刻意为之。想在向导里看到 macOS,需要装一个社区维护的解锁补丁,它的作用是向 VMware 的客户机配置数据库里注入 Apple 相关条目,并对部分二进制文件做对应的处理。这个补丁和 VMware 的主版本号是强绑定的:17.x 的 VMware 要配 17.x 对应的补丁版本,用错版本轻则客户机列表出不来,重则 VMware 启动直接崩溃。
近两年 VMware Workstation 对个人使用放开了授权,从官网下载安装即可,不需要再折腾激活相关的东西,这倒是省了不少事。安装时建议把安装路径保持默认,因为解锁补丁需要往安装目录里写文件,路径太深或者带中文都可能出问题。
补丁的执行流程本身不复杂,它的目录里有个批处理脚本,右键以管理员身份运行,脚本会自动停掉 VMware 的相关服务、备份原文件、替换成打了补丁的版本。执行之前必须彻底退出 VMware,包括右下角托盘里的图标和后台的认证服务,只在窗口上点关闭是不够的。我遇到过一次脚本跑完没生效,排查半天才发现是托盘进程还在占着 vmware-vmx.exe 的文件句柄,导致替换失败但脚本没有报错。
脚本执行失败的高频原因有几个,按出现频率排:没有用管理员权限运行;补丁目录放在带空格或中文的路径下(比如“我的文档”);杀毒软件在替换二进制文件时把它当成可疑行为拦截了;VMware 的服务没有完全停止。脚本跑完之后,打开 VMware 新建虚拟机,如果操作系统列表里出现了 Apple Mac OS X 这一项,说明补丁生效了。
2. 让 VMware 拿回 VT-x:宿主机环境的清理
2.1 Hyper-V 和内存完整性是怎么抢走虚拟化权限的
这是整个流程里最隐蔽、也最容易浪费时间的坑。CPU 的硬件虚拟化能力(Intel 的 VT-x、AMD 的 AMD-V)同一时刻只能被一个虚拟化管理程序占用。Windows 10 和 Windows 11 为了支持 WSL2、Windows 沙盒、Docker Desktop、内核隔离这些功能,默认可能会启用一个叫 Hyper-V 的组件,它会先一步把虚拟化权限拿走。这时候 VMware 再去申请,只能退化成纯软件模拟模式,速度慢到无法使用,或者干脆弹出“此平台不支持虚拟化的 Intel VT-x/EPT”之类的报错。
更麻烦的是,即便你在“启用或关闭 Windows 功能”里把 Hyper-V 的勾去掉了,虚拟化权限也未必回来,因为还有几个独立的开关在起作用。需要一并处理的包括:
- “Windows 虚拟机监控程序平台”
- “虚拟机平台”
- “Windows 沙盒”
- “适用于 Linux 的 Windows 子系统”
- 设置 → 隐私和安全性 → Windows 安全中心 → 设备安全性 → 内核隔离 →内存完整性
- 组策略中基于虚拟化的安全性(VBS)相关项
其中“内存完整性”是最常被忽略的一个。它藏在安全中心的二级菜单里,默认在新装的 Windows 11 上是打开的,只要它开着,Hyper-V 的管理程序就会被加载,VMware 就永远拿不到原生 VT-x。关掉它需要重启,而且部分主板在重启后会自动重新打开,需要去 BIOS 里把对应的虚拟化安全开关也关掉。
命令行层面还有一步可以确认,以管理员身份打开命令提示符执行:
bcdedit /set hypervisorlaunchtype off这条命令保证 Windows 启动时不加载 Hyper-V 的管理程序。执行完之后必须重启,重启后打开任务管理器,切到性能选项卡,点 CPU,右下角会显示“虚拟化:已启用”或者“已禁用”。这里的“已启用”指的是 CPU 支持虚拟化并且 BIOS 里开了,跟 Hyper-V 是否占用无关,所以还需要在 VMware 的日志里确认一次。
2.2 关了 Hyper-V 之后 Docker 和 WSL2 怎么办
这里有个真实存在的取舍:Hyper-V 关了,Docker Desktop 默认的 WSL2 后端和 WSL2 本身就用不了了。这个问题没有完美答案,只能根据自己的使用节奏做切换。
我自己的做法是写两个批处理脚本放在桌面,一个切到“VMware 原生模式”,一个切到“WSL 模式”,每次切换后重启系统。脚本内容大致是这样:
@echo off :: switch-to-vmware.bat bcdedit /set hypervisorlaunchtype off echo 已切换到原生虚拟化模式,重启后生效。 shutdown /r /t 5@echo off :: switch-to-wsl.bat bcdedit /set hypervisorlaunchtype auto echo 已切换到 Hyper-V 模式,重启后生效。 shutdown /r /t 5如果只是偶尔用一次 macOS 虚拟机,这个切换成本可以接受。如果你的日常工作强依赖 WSL2 和 Docker,那就需要考虑别的方案,比如把 macOS 环境放到另一台机器上,或者干脆用一台独立的 Mac 设备。不要指望两者共存,至少在 macOS 客户机这条路上不存在两全其美的配置。
2.3 BIOS 里的三个开关和一次验证
进 BIOS 需要关闭或者打开的项在不同主板上的叫法差异很大,但核心就那么几个:
- Intel Virtualization Technology / AMD-V:必须开启,这是前提。
- VT-d / IOMMU:虚拟机直通设备时用得到,跑 macOS 虚拟机不是必须,开着也无害。
- Execute Disable Bit / NX:必须开启,很多系统引导失败和这个有关。
- Secure Boot:一般保留开启即可,如果引导异常可以临时关闭试一次。
- 基于虚拟化的安全性 / VBS:如果主板有这个选项,建议关闭。
配好之后,最直接的验证方式是启动一次那台不存在的虚拟机——把前面配置好的 vmx 文件用 VMware 打开,开机看是否出现 Apple 的引导界面。如果 VMware 直接弹出虚拟化不可用的对话框,说明第二章的清理还没做干净,回去把内核隔离和 hypervisorlaunchtype 再确认一遍,别急着怀疑镜像或者补丁。
3. 镜像与补丁:安装包里最容易翻车的两个文件
3.1 镜像格式的选择直接决定能不能引导
VMware 的光驱只能挂载 ISO 格式的镜像,而 macOS 官方分发的安装介质是 pkg 或者 dmg 格式,没法直接挂。社区通常提供两种处理好的格式:一种是扩展名为.iso的版本,另一种是扩展名为.cdr的版本。cdr 本质上就是在 dmg 前面补了一段头信息使其能被识别为光盘镜像,两者都可以被 VMware 当作启动介质,选择哪个取决于你从哪个渠道拿到的文件。
版本选择上,我建议从macOS 13 Ventura 或 14 Sonoma起步。原因很实际:太老的版本(High Sierra、Mojave)虽然对硬件要求低,但很多现在的开发工具和浏览器已经不支持了,装完你会发现没什么能用的;太新的版本(15 及以上)在 Intel 架构的虚拟机上遇到的兼容问题会明显增多,比如引导阶段对 T2 芯片相关检查的依赖、对新指令集的要求等。13 和 14 是当前兼容性和可用性平衡得最好的两个版本。
镜像文件一般在 12GB 到 16GB 之间,必须放在 SSD 上。如果你放在机械盘上,安装过程中的读取速度会成为最大的瓶颈,用户在等待 40 分钟之后往往会以为程序卡死然后强行关闭,实际上它只是在慢慢读数据。
3.2 解锁补丁的正确执行姿势
前面提过执行补丁的几个前提,这里给出一套完整的检查顺序,按这个顺序走基本不会出问题:
- 确认 VMware Workstation 已经完全退出,托盘图标消失,服务列表里没有 vmware 开头的服务在运行。
- 确认补丁的版本号和 VMware 的主版本号一致。
- 把补丁解压到一个纯英文、无空格的短路径下,比如
D:\unlocker\。不要放在桌面或者“下载”文件夹里,这两个路径在中文系统上会被展开成带中文的完整路径。 - 临时关闭杀毒软件的实时防护,或者把 VMware 的安装目录加入白名单。
- 右键批处理脚本,以管理员身份运行,观察输出窗口有没有报错信息。
- 脚本结束后,重新启动 VMware,新建虚拟机,检查操作系统列表。
补丁执行完之后,还有一个附带效果需要知道:VMware 的虚拟机设置菜单里会多出一项“安装 VMware Tools”的可用项。如果这一项一直是灰色的,说明补丁没有完全生效,后面安装 Tools 的那一步会无从下手。
3.3 虚拟机文件夹该放哪
这个问题看着琐碎,实际上踩坑的人很多。默认情况下 VMware 会把虚拟机放在用户目录下的“文档\Virtual Machines”里,这个位置有几个问题:路径里带中文,路径深度长,而且如果用户开启了 OneDrive 的文档同步,整个虚拟机文件夹会被同步到云端,几十 GB 的文件会把同步盘塞爆,同时 VMware 在写磁盘的时候会和同步进程抢文件锁。
我的习惯是单独建一个目录,比如D:\VM\macos14\,结构大概是虚拟机文件夹、镜像文件、快照备份各占一级。这个目录要做两件事:一是把 Windows Defender 的实时扫描排除掉,二是不要放在任何云同步目录里。磁盘操作的性能差异在安装阶段尤其明显,排除扫描之后安装时间通常能缩短两到三成。
4. 新建虚拟机:向导里每个选项背后的理由
4.1 客户机操作系统和硬件参数怎么选
打开新建虚拟机向导,选择“自定义(高级)”而不是“典型”,因为自定义模式下你能控制磁盘控制器类型和虚拟硬件版本,这两个在后面都可能需要调整。客户机操作系统选 Apple Mac OS X,版本选 macOS 13 或 macOS 14。如果这里只有 Mac OS X 的老版本选项,选个最接近的也可以,后期改 vmx 里的参数就行。
接下来的参数我一般这样填:
- 内存:8GB(宿主机 16GB 的情况)
- 处理器:2 个插槽 × 2 个核心 = 4 个 vCPU
- 网络类型:NAT
- 磁盘控制器:SATA(这一点很关键,SCSI 在 macOS 引导阶段可能识别不到)
- 磁盘容量:100GB,选择“将虚拟磁盘存储为单个文件”
- 光驱:使用 ISO 映像文件,指向准备好的 cdr 镜像
“存储为单个文件”比“拆分成多个文件”性能稍好,但如果你打算把虚拟机放在 exFAT 格式的外置盘上,要注意单文件不能超过 4GB 的限制——100GB 的磁盘文件会远超这个限制,所以外置盘必须是 NTFS 或者 APFS 格式。
4.2 关机状态下必须补的 vmx 参数
向导创建的虚拟机开不了机,这是正常现象,因为还缺几行关键参数。关掉虚拟机,在虚拟机文件夹里找到.vmx文件,用记事本打开,在末尾追加以下内容。修改之前先复制一份备份,这个习惯能省下很多重装的时间。
smc.present = "TRUE" smc.version = "0" firmware = "efi" hw.model.reflectHost = "FALSE" hw.model = "iMac19,1" board-id.reflectHost = "FALSE" board-id = "Mac-AA95B1DDAB278B95" serialNumber.reflectHost = "FALSE" serialNumber = "C02XXXXXXXXX"逐行解释一下。smc.present和smc.version是让 VMware 向客户机暴露一个兼容的系统管理控制器,版本必须写 0,写别的值在很多版本上会直接导致引导失败。firmware = "efi"保证使用 UEFI 引导方式,macOS 从 10.8 之后就不再支持传统 BIOS 引导了,这一行漏掉的话会出现“Operating System not found”。
hw.model这一组参数的作用是伪装虚拟机的硬件型号。macOS 的安装器会检查当前硬件标识是否在允许列表里,如果直接暴露宿主机的真实型号,安装器大概率会拒绝继续。常用的型号值有iMac19,1、iMacPro1,1、MacPro7,1这几个,如果某一个型号在安装时被拦截,换另一个试试,不同版本的系统对型号的接受程度略有区别。序列号部分随便填一串符合格式的字符即可,不需要和真实设备对应。
如果你是 AMD 平台的用户,还需要额外加一组 CPU 掩码参数,把 CPU 的厂商识别串伪装成 Intel 的,否则引导会直接失败。Intel 平台不需要这一步。
4.3 显存、3D 加速和 USB 控制器
再补三组参数,它们直接影响使用体验:
svga.vramSize = "268435456" svga.autodetect = "FALSE" svga.maxWidth = "2560" svga.maxHeight = "1600" mks.enable3d = "FALSE" usb_xhci.present = "FALSE" ethernet0.virtualDev = "e1000e"svga.vramSize的单位是字节,268435456 就是 256MB,如果你打算在虚拟机里做点图形相关的工作,可以调到 536870912(512MB),但不要超过宿主机显存的一半。svga.maxWidth和maxHeight决定分辨率上限,设得比你的实际显示器宽高略大一些,避免全屏时被拉伸。
mks.enable3d这一行我强烈建议在安装阶段保持 FALSE。开启 3D 加速之后,部分显卡驱动组合会在引导阶段出现黑屏或者花屏,让人误以为是镜像坏了,实际只是 3D 加速的兼容性问题。等系统装完、Tools 装好、确认一切正常之后再回来把它改成 TRUE 试一次,如果画面异常就改回去。
usb_xhci.present控制是否暴露 USB 3.x 控制器。安装阶段关掉它,用 USB 2.0 兼容模式,可以规避一部分设备识别问题。系统装好之后再打开,就能用 USB 3.0 的速度接外设了。
5. 安装 macOS:从引导到看见桌面
5.1 抹盘这一步为什么绝对不能跳过
虚拟机开机之后,会先进入 macOS 的恢复环境,界面是深色的,顶部有菜单栏。第一步不是点“安装 macOS”,而是先打开“磁盘工具”。这一步新手最常跳过,结果是在安装器里找不到任何可选的目标磁盘,然后开始怀疑镜像有问题。
在磁盘工具的左侧列表里,点左上角的“显示”菜单,选择“显示所有设备”,这样能看到顶层的虚拟磁盘设备而不只是卷。选中那个名叫 VMware Virtual Disk 的顶层条目,点“抹掉”,在弹出的对话框里填三项:名称可以叫 Macintosh HD,格式选APFS,方案选GUID 分区图。这三项里方案最容易选错,默认可能是“主引导记录”,选错了之后安装器依然找不到目标盘。
抹完之后关掉磁盘工具,回到安装界面,这时候目标磁盘就会出现在列表里了。整个安装过程会经历多次自动重启,这是正常的流程设计:第一遍把系统文件拷贝到磁盘,第二遍从新磁盘引导并完成准备,第三遍做最后的配置。至少要经历两到三次重启,看到重启不要慌,也不要在重启的瞬间强行关机。
5.2 哪些“卡住”是正常的,哪些是真死了
安装阶段的时间预期需要提前建立好,不然很容易在错误的时刻做出错误的决定。在 SSD 上,从抹盘到进入桌面大约需要 30 到 60 分钟;如果中间有阶段停留在“剩余 12 分钟”很久,那通常是正常现象,因为那段时间在做文件系统元数据的整理,进度条本身并不线性。
判断是真卡死还是慢,有个很实用的方法:打开宿主机的任务管理器,看磁盘的读写曲线。如果磁盘还在持续读写,说明安装器还在干活,耐心等;如果磁盘读写完全归零并且持续超过 15 分钟,那大概率是真的卡住了,这时候先尝试重启虚拟机再走一遍;连续失败两次以上,再去怀疑镜像文件或者 vmx 参数。
还有一个容易被忽略的原因:内存给少了。macOS 安装在最后阶段有个对内存要求较高的步骤,如果虚拟机只有 4GB 内存,可能在这个阶段反复失败或者无限重启。临时把内存调到 8GB 以上,装完再调回去,这个方法解决过不少“莫名其妙装不上”的案例。
另外注意安装过程中不要随手动宿主机的资源,比如同时跑一个大型编译或者下载几十 GB 的东西,磁盘和 CPU 被抢占之后安装时间会被拉长好几倍。
5.3 进桌面之后的几件必做的事
第一次进入桌面,系统会走一遍初始化向导,包括选择地区、键盘布局、是否登录账号等。登录账号这一步可以跳过,虚拟机里的硬件标识是伪装的,用它登录账号可能会触发额外的身份验证,把它当纯测试环境用更省心。
进桌面之后建议立刻做这几件事,能让后续体验顺畅很多:
- 打开“系统设置 → 隐私与安全性”,如果之前有被拦截的应用,在这里点“仍要打开”。
- 关闭 Siri、关闭“聚焦”的索引:在终端执行
sudo mdutil -a -i off,能明显降低后台磁盘 IO。 - 打开“辅助功能 → 显示”,勾选“减少透明度”和“减少动态效果”,动画少了之后整个系统反应速度会有肉眼可见的提升。
- 关闭自动下载系统更新,避免某天开机突然开始下载十几 GB 的系统包。
做完这些,立刻在关机状态下打一个快照。这是虚拟机方案最大的优势,一个干净的基线快照能让你在任何一次实验失败之后几秒钟回到原点。开机状态下打快照会包含内存状态,文件体积大很多,关机状态的快照更精简。
6. VMware Tools:装完之后体验才像一台机器
6.1 darwin.iso 的挂载方式
不装 VMware Tools 的 macOS 虚拟机,分辨率固定在 1024×768 无法调整,鼠标移动会有迟滞感,剪贴板不通,时间同步也不正常。Tools 在 macOS 客户机上对应的安装包是 darwin.iso,它就在 VMware 的安装目录下。注意版本匹配:给较老的客户机系统准备的还有一份 darwinPre15.iso,装新系统用 darwin.iso。
挂载的方式是在虚拟机设置里,选中 CD/DVD 设备,改成“使用 ISO 映像文件”,指向安装目录下的 darwin.iso,然后勾选“启动时连接”。如果虚拟机菜单里的“安装 VMware Tools”是灰色的,说明解锁补丁没有完全生效,回到第三章检查。
挂载之后进入 macOS,桌面上会出现一个光盘图标,双击打开,里面有个“安装 VMware Tools”的应用。直接双击可能会提示“来自身份不明的开发者,无法打开”,这时候右键点它选择“打开”,在弹出的二次确认里点“打开”。也可以在系统设置的隐私与安全性里找到被拦截的记录,点“仍要打开”。
安装过程中系统会要求输入管理员密码,然后走一个标准的安装流程,可能需要几十秒到几分钟。安装完成后会提示重启,重启之后分辨率就会自适应窗口大小,鼠标也不会再有那种拖影感了。
6.2 三种网络模式的取舍
VMware 提供三种网络模式,它们的区别直接影响你能不能从宿主机或者局域网里的其他设备访问虚拟机里的服务。这张表是我自己常用的对照:
| 模式 | 虚拟机能否上网 | 宿主机能否访问虚拟机 | 局域网其他设备能否访问 | 典型用途 |
|---|---|---|---|---|
| 仅主机 | 否 | 能 | 否 | 完全隔离的测试环境 |
| NAT | 能 | 需要端口转发 | 否 | 默认选择,最省事 |
| 桥接 | 能 | 能 | 能 | 需要被其他设备访问的场景 |
大多数时候用 NAT 就够了,虚拟机通过宿主机上网,宿主机访问虚拟机需要在虚拟网络编辑器里配一条端口转发规则。举个实际例子:你在虚拟机里用python -m http.server 8000起了一个服务,想让宿主机浏览器访问,就在虚拟网络编辑器里把宿主机的某个端口(比如 18000)映射到虚拟机的 8000 端口,然后在宿主机上访问http://127.0.0.1:18000即可。这个功能在调试移动端页面时特别有用,配合宿主机的抓包工具可以直接看到虚拟机的请求。
桥接模式适合需要被局域网内手机、平板访问的场景,虚拟机在这种模式下会从路由器拿到一个独立的 IP,和宿主机处于同一网段,其他设备直接访问这个 IP 就行。缺点是如果宿主机的网络环境有权限管控(比如公司网络),桥接可能会拿不到 IP,这时候换回 NAT。
6.3 共享目录在 macOS 客户机上为什么不好用
VMware 的共享文件夹功能依赖 HGFS 驱动,这个驱动在 Windows 和 Linux 客户机上很稳,但在 macOS 客户机上支持一直比较弱,即便 Tools 装好了,共享目录也可能挂载不上或者挂上了读写异常。
我的替代方案有三个,按便利程度排序。第一种是反过来做:在 Windows 侧把要共享的目录设成 SMB 共享,然后在 macOS 里用 Finder 的“前往 → 连接服务器”,输入smb://宿主机的IP访问。NAT 模式下宿主机的地址通常是虚拟网络的网关地址,一般是192.168.x.1这种形式,在虚拟机的网络设置里能看到具体值。
第二种方案更适合临时传文件。在 Windows 侧打开一个存放文件的目录,执行:
python -m http.server 8000然后虚拟机里的浏览器访问http://192.168.x.1:8000,就能直接浏览并下载这些文件。这个方案的优点是零配置,不需要 Tools 支持,也不需要配共享权限。
第三种方案适合需要双向传输的场景:在 macOS 里打开“系统设置 → 通用 → 共享 → 远程登录”,然后在 Windows 侧用 scp 命令把文件推进去,或者用任何支持 SFTP 的客户端。这种方式速度最快,也最稳定,代价是多敲几行命令。
7. 高频故障的定位链路
7.1 卡在 Apple 标志、出现五国语言界面、无限重启
这三个现象经常一起出现,根因也高度重叠。按排查成本从低到高,我一般这样查:
先确认宿主机侧的原生虚拟化是否真的生效。打开任务管理器看虚拟化状态,再翻一下虚拟机目录里的vmware.log,搜索MONITOR MODE或者在启动时是否有关于 VT-x 不可用的提示。这一步能排掉将近一半的案例,很多人折腾到重装系统,其实只是内存完整性还开着。
接着检查 vmx 参数。smc.version是不是 0、firmware是不是 efi、hw.model是不是写了一个合理的型号值、mks.enable3d是不是 FALSE。这几个参数任何一个不对都可能导致引导阶段直接崩溃。特别是换过型号值之后,某些版本的安装器会有缓存,建议关机后重新启动而不是用重置。
再往下一步就是内存和镜像。安装阶段内存低于 6GB 会导致反复重启,这个现象和镜像损坏很像,容易误判。判断方法是看日志里有没有关于内存分配失败的记录,或者干脆把内存临时加到 8GB 再试一次。如果调到 8GB 还失败,再用校验工具确认镜像的哈希值是否和来源一致,下载不完整的镜像是最隐蔽的坑之一。
7.2 出现 EFI Shell 界面或者提示找不到操作系统
这个现象的直接原因是虚拟机没有从光驱引导。检查三处:光驱是不是指向了正确的 cdr 或 iso 文件、光驱有没有勾选“启动时连接”、虚拟机的引导顺序里光驱是否在硬盘之前。引导顺序可以在虚拟机设置的“选项 → 高级”里调整,或者在开机瞬间按 ESC 进入 UEFI 菜单手动选择。
如果这些都确认了还是进 EFI Shell,那大概率是镜像本身不可引导。有些从 dmg 直接改后缀得到的文件并不能被当作可引导光盘,必须是经过完整转换流程生成的 cdr 或者 iso。遇到这种情况不要继续折腾参数,换一个镜像源是最快的路径。
还有一种情况是之前挂载过 Tools 的 darwin.iso 后忘记卸载,导致开机优先从这个非引导镜像启动,进入 EFI Shell。把光驱改回指向系统镜像或者干脆断开光驱连接,就能恢复正常引导。
7.3 安装 VMware Tools 时提示“继续运行脚本未能在虚拟机中成功运行”
这个报错在 Tools 安装过程中相当常见,表现形式是安装进行到某个阶段突然弹出错误对话框。它的本质是安装器内部的某个脚本执行失败了,常见原因是系统扩展被安全策略拦截、Tools 版本和客户机系统版本不匹配、或者之前装过一次失败的残留导致状态不一致。
处理的办法按顺序试:先在系统设置的隐私与安全性里查看有没有被拦截的系统扩展提示,允许之后重启再装一次;如果还是失败,用卸载脚本把旧的残留清掉(Tools 安装包里有卸载选项),重启之后重新安装;再不行就换一个版本的 darwin.iso,不同版本的 VMware 附带的 Tools 对新系统的支持程度不同,用新版本的 Tools 去装老系统,或者反过来,都容易出问题。
如果只是共享文件夹相关的组件装不上,其实可以忽略这个错误。分辨率、剪贴板、鼠标这些核心功能主要依赖显卡和输入相关的驱动,这些装上了就能用,共享文件夹在 macOS 上本来也有别的替代方案。
8. 装完之后:性能调优、快照策略与搬迁
8.1 让虚拟机在日常使用中不那么卡
系统装好之后,性能调优的空间其实不大,因为虚拟机的瓶颈主要在磁盘和图形这两个地方。磁盘侧能做的两件事前面提过:关掉 Spotlight 索引,以及把虚拟机目录从 Windows Defender 的实时扫描里排除掉。第二件事的效果常常被低估,实时扫描会在每次虚拟机写磁盘时插一道检查,安装大型软件时差异非常明显。
图形侧可以做的是把显存调到 512MB,然后把 3D 加速重新打开测试一次。开启 3D 之后界面的滚动和窗口动画会明显顺滑,但如果出现花屏、黑屏、窗口内容不刷新这类现象,就说明宿主机的显卡驱动和虚拟的图形栈有兼容问题,改回 FALSE 继续用。
宿主侧还有两个小调整值得做:把 Windows 的电源计划改成“高性能”,避免 CPU 在虚拟机跑满的时候降频;在 VMware 的虚拟机设置里把“优先使用后台服务”打开,这样虚拟机的 CPU 调度优先级会更高一些。
8.2 快照和克隆的正确用法
快照是虚拟机方案最值钱的功能,但用法不对会反噬。我的习惯是只在三个时间点打快照:系统装完并做完基础设置之后打一个基线快照;准备做大版本系统升级或者装来源不明的软件之前打一个临时快照;某个能稳定复现问题的环境状态存一个快照用于对比测试。
不要频繁打快照,也不要在同一个分支上叠超过三四个快照。快照文件是增量记录的,链条越长,每次磁盘写入需要的额外操作越多,性能衰减会累积。用完之后及时删除不需要的快照,删除大快照会触发一次磁盘合并操作,这个过程可能需要十几分钟,别在中途强制关机。
如果在同一台宿主机上克隆第二台虚拟机做对比测试,克隆完之后必须修改两处标识,否则两台机器的网络会冲突:ethernet0.address改成一个新的 MAC 地址,uuid.bios改成一组新的值。VMware 的克隆向导在多数情况下会自动处理,但如果用的是手动复制文件夹的方式,就得自己改。
8.3 把整个虚拟机搬到另一台机器或者外置盘
有时候需要在不同机器之间转移这套环境,比如公司一台、家里一台。做法很直接:把虚拟机彻底关机(不是挂起),然后把整个.vmwarevm文件夹拷贝到目标位置,在新机器上用 VMware 打开里面的.vmx文件就行。拷过去的路径如果和原来不一样,VMware 会问是“我已移动”还是“我已复制”,选“我已移动”可以保留原来的网络配置,选“我已复制”会给虚拟机分配新的标识。
往移动硬盘或者 U 盘上拷的时候有几个硬性要求:盘的接口至少是 USB 3.0,USB 2.0 的传输速度会让虚拟机在运行中频繁卡顿;文件系统必须是 NTFS 或 exFAT 这类支持单文件超过 4GB 的格式,FAT32 会在拷贝到一半时报错;拷完第一次在新机器上运行之前,确认那台机器的虚拟化开关也是打开的,否则会出现开机即报错的假象。
如果目标机器的 CPU 平台和原机器不同(比如从 Intel 换到 AMD),还需要重新调整 vmx 里的 CPU 掩码参数,具体做法参考第四章提到的内容。跨平台迁移多少会有些折腾,但比起重新装一遍,改几行配置还是划算得多。
我在虚拟机里折腾 macOS 这几年,最大的体会是:出问题的时候不要凭直觉乱改参数,先看日志。vmware.log每次开机会重新生成,里面记录了引导链路上每个阶段的状态和报错,把报错关键词丢进搜索引擎,找到的答案往往比盲目重装精准得多。另一个习惯是每完成一个稳定状态就打一个快照,把虚拟机变成可以随时回退的实验台——这套环境真正的价值不在于它能跑多快,而在于你可以放心地把系统搞坏,然后花十秒钟回到原点。