简介Unlocker 2.1.1 for VMware 是专门用来在 VMware Workstation/Player 14 和 Fusion 10 上解锁 macOS 安装能力的工具包面向需要虚拟化运行苹果系统的 IT 运维、开发测试人员以及技术爱好者能够解决虚拟机软件默认不支持 macOS 的常见限制。该版本已删除对 ESXi 6.x 的实验性支持并特别提醒升级前必须先完整地卸载旧版 unlocker否则可能导致 VMware 无法正常使用建议使用者严格按说明顺序处理。压缩包共 21 个文件约 15.44MB主要包含 Windows 批处理脚本、Linux/macOS Shell 脚本、可执行程序、Python 辅助脚本与说明文档分别覆盖不同平台下的安装、卸载、工具下载和配置校验等环节方便在多种宿主机环境中快速部署。目前已有 4128 人次学习下载适合需要搭建 macOS 虚拟机实验环境的中高级 VMware 用户包内还附有更新日志、许可证及说明文本可帮助理解版本迭代思路是一套实用且完整的一站式虚拟化解锁工具集。1. Unlocker2.1.1 for VMware让 VMware 认得出 macOS 客户机同事扔过来一个 .vmx说里面装好了 macOS可我按下“开启此虚拟机”VMware 立刻弹出一句“此客户机操作系统不受支持”。这不是哪一步配错了而是 VMware Workstation 本来就不把 macOS 放进可用客户机列表。Unlocker2.1.1 for VMware 起的作用就是解除这道限制给 vmware-vmx 打完补丁之后新建虚拟机向导里会出现 macOS 系统选项已经导出的 vmx 也能正常引导。这工具适合三类人想在 PC 上装 macOS 虚拟机做开发、联调或打包验证的开发者维护测试矩阵、需要定期重建 mac 客户机的测试工程师还有手里攒了一批老 mac 虚拟机模板、升级 VMware 后全部打不开的存量用户。后面两种人最怕的不是装不上而是补丁失效后不知道去哪里找原因。2. 解锁的关键不在 guestOS 配置为什么必须改 vmware-vmx 与虚拟 SMC2.1 客户机类型白名单VMware 为什么不认 macOSVMware Workstation 启动虚拟机时首先要判断客户机操作系统的类型。这个判断不是靠你填的字符串而是靠 vmware-vmx 内置的类型表与各类型对应的设备模型。Windows、Linux 各发行版在类型表里有完整条目支持模块会在虚拟机创建时自动挂载macOS 的 Darwin 内核虽然也是 UNIX 系但它的引导方式对固件和 SMC 的要求与普通 x86 系统差别很大VMware 不打算在 Workstation 产品线上为它提供官方支持于是类型表里根本没有它。所以“新建虚拟机向导里选不到 macOS”不是界面做得不够好而是底层设备模型不支持。即便你手动在 vmx 里写一行guestOS darwin20虚拟机启动时 vmware-vmx 会按未知类型拒绝加载报错信息往往还是“无效的客户机操作系统”。你可以做个实验验证这道白名单随便复制一份 Windows 虚拟机的 vmx把 guestOS 改成 darwin20然后启动。VMware 大多会在配置检查阶段直接弹窗报错连硬件初始化都不会开始。这说明类型检查发生在引导之前虚拟机根本没机会走到 Darwin 内核那里。2.2 补丁改了什么东西Unlocker 的思路是对 vmware-vmx 可执行文件做二进制补丁把这个类型检查的判定路径打开。补丁落点通常是两处一是把 darwin 类型放进允许枚举二是让虚拟机固件层能模拟 macOS 引导需要的 SMC系统管理控制器状态。SMC 对 macOS 来说不是普通 PC 上的“南桥芯片”它在引导早期要向系统固件报告设备信息macOS 系虚拟机的 smc.version 字段取值和普通 PC 虚拟机完全不同。这也解释了为什么“只改一行配置”总被证明无效你写得再像vmware-vmx 这个黑匣子本身不认识 darwin它就按老流程走。相比之下Unlocker 用脚本在可执行文件里做特征替换vmware-vmx 运行时才会把 mac 客户机当作可支持对象去加载设备模型。补丁过程听起来像是某种“本地破解”其实脚本逻辑非常保守先定位 vmware-vmx 文件做一份完整备份再在匹配的特征码位置替换若干字节。多数 unlocker 版本执行完会在同目录留下 backup 文件夹里面是原始文件。这也是 uninstall 脚本能还原的原因——它找到那份备份复制回去。2.3 先分清三种状态原始、解锁、恢复拿到包后别急着双击。先搞清楚手里的 VMware 处于哪种状态原始状态vmware-vmx 未被修改macOS 选项不存在解锁状态补丁已打入向导里能选 macOS且能启动 mac 虚拟机恢复状态通过 uninstall 脚本把备份的原始 vmware-vmx 还原回去。社区里大多数解锁包都带一对脚本Windows 常见是 win-install.cmd 和 win-uninstall.cmdLinux 常见是 install.sh / uninstall.sh。文件名各版本略有差异但逻辑一致install 前先备份当前 vmware-vmxuninstall 时再还原。想确认当前处于哪种状态最直接的办法是比对文件哈希。Windows 上打开管理员命令行certutil -hashfile C:\Program Files (x86)\VMware\VMware Workstation\vmware-vmx.exe SHA256 certutil -hashfile C:\path\to\unlocker\backup\vmware-vmx.exe SHA256两个输出一致说明是原始或已恢复状态不一致说明补丁还在。路径按实际安装位置调整Program Files 有空格要带引号。这套方法在 VMware 升级后尤其有用不用每次靠“能不能开机”去猜补丁状态。3. 在 VMware Workstation 上跑通 Unlocker 2.1.1从关闭服务到验证可用3.1 第一步释放 vmware-vmx 的文件占用Unlocker 要替换的文件是 vmware-vmx它在虚拟机运行时一直被进程占用。如果 VMware 没关干净脚本会在写文件时失败常见表现是执行后看不到任何效果日志里留下一句 cannot open/access。我一般的习惯是先退托盘图标再由管理员权限的命令行把相关进程和服务停掉。以 Windows 为例管理员权限的命令提示符里执行:: 管理员权限执行结束工作台与虚拟机主进程 taskkill /F /IM vmware-tray.exe taskkill /F /IM vmware-vmx.exe :: 停掉授权服务不同版本服务名可能略不同 net stop VMware Authorization Service如果 taskkill 返回“没有找到进程”反而说明本来就没在运行这是正常的。会残留的往往是 vmware-vmx.exe而不是托盘进程。新手如果分不清服务名有个更省事的做法注销当前 Windows 用户再登录VMware 的后台进程会随会话一并清掉或者直接重启宿主机后进命令行。相比之下我还是习惯 taskkill不用动系统。注意“虚拟机设置”里的正常关机和这里杀进程不一样。vmware-vmx 关机后进程会自动退出但只要 VMware Workstation 主界面还开着托盘和授权服务就还在补丁脚本同样可能写失败。所以这一步别偷懒。3.2 第二步执行安装脚本把 unlocker 压缩包解压到不含空格、不含中文的路径比如C:\tools\unlocker21。然后管理员命令行切到该目录执行安装脚本cd /d C:\tools\unlocker21 dir win-install.cmd脚本会依次完成几件事定位 VMware 安装目录、备份当前 vmware-vmx.exe 到包内的 backup 位置、对 vmware-vmx.exe 打补丁。有的版本还会同时处理 darwin.iso那是给 mac 虚拟机装 VMware Tools 用的镜像一并写入安装目录。为什么强调用命令行而不是双击双击 cmd 文件时当前工作目录不一定是你解压的目录脚本如果按相对路径找 VMware 安装路径或备份目录就会找错。用cd /d切过去再执行至少保证工作目录和脚本位置一致。如果 Win10/Win11 的安全策略拦了脚本先右键脚本文件 → 属性 → 勾选“解除锁定”再执行。脚本如果正常cmd 窗口里应当出现类似 backup existing vmware-vmx 的提示然后进入 patching 过程。如果输出停在“无法打开文件、访问被拒绝”十有八九是 VMware 进程没清干净。脚本不会自动重试你需要把残留进程处理掉再重新执行一次。3.3 第三步用新建虚拟机向导验证跑完脚本启动 VMware Workstation新建虚拟机。到“客户机操作系统”那一步如果看到 macOS 系列选项一般按大版本列出如 macOS 10.15 / macOS 11 / macOS 12说明补丁已经写入。这一步不需要额外操作只要下拉框出现了就是成功。如果是旧的 macOS 虚拟机直接双击 vmx 也能跑VMware 不再报“不受支持”而是进入正常引导流程。若到了这一步依旧被拒大概率是补丁没写进去回到第 5 章按清单排查。验证时有个容易误判的点向导里能看到 macOS 选项但虚拟机启动后还是报“不支持”这种一般是 vmx 里手动写错了 guestOS 值或者硬件版本过高和补丁本身无关。新建向导默认生成的 vmx 是最干净的建议先用向导生成一台再改配置别一上来就手写。3.4 Linux 宿主机上的另一套执行顺序标题是 for VMware但这个解锁器同时被大量用在 Linux 版 Workstation 上。Linux 上的要点是先停服务再动二进制。如果你跑的是带图形桌面的发行版可以直接用 systemctl 管理 VMware 服务sudo systemctl stop vmware # 备份原始文件出问题时可以快速回滚 sudo cp /usr/lib/vmware/bin/vmware-vmx /root/vmware-vmx.bak.$(date %F) cd /opt/unlocker21 ls -l # 包内脚本命名不完全统一通常是 install.sh 或 linux-install.sh以实际解压内容为准 sudo ./install.sh sudo systemctl start vmware路径以实际安装位置为准不同发行版的/usr/lib和/usr/local结构不一样。如果系统是老式 init 脚本管理 VMware没有 systemd 单元就执行sudo service vmware stop或直接调/etc/init.d/vmware stop原理一样先停服务再补丁再启动。执行前记得确认脚本有执行权限。解压到 Linux 后文件权限可能丢失先chmod x install.sh再运行避免出现 permission denied 这种不必要的报错。Linux 下脚本执行失败最常见的原因还是 VMware 服务未完全停止和 Windows 下的体验几乎一样。4. macOS 虚拟机装完后的关键配置硬件版本与 .vmx 参数怎么调4.1 硬件兼容性版本先别急着升解锁成功后新建虚拟机向导会询问硬件兼容版本。已有 vmx 的老用户常犯一个错被 VMware 提示“此虚拟机的硬件版本较旧是否升级”后无脑点“是”。升级动作会重写虚拟设备集合包括芯片组、ACPI 表、SMC 设备描述。macOS 引导对这些描述相当敏感升级后如果新版本与 unlocker 补丁的特征不匹配最容易出现启动阶段直接卡住这不是配置问题是版本组合问题。| 场景 | 建议 | | 已有 macOS 虚拟机 | 保留原硬件版本不做升级 | | 新建 macOS 虚拟机 | 采用宿主默认版本通常为 15.x / 16.x | | 批量维护模板 | 所有模板统一版本并在模板内记录 .vmx 差异 |如果你的 VMware Workstation 已经升级到很新的版本而 unlocker 还是 2.1.1 这个老版本新建虚拟机时可以把硬件兼容版本手动往回调一档再创建兼容性反而更稳。硬件版本不影响客户机里能跑什么系统只影响虚拟设备集合的呈现方式。4.2 .vmx 里需要手动校准的字段用向导创建的 mac 虚拟机一般会自动写好 guestOS 与 SMC 相关字段手工从 vmx 创建或从模板克隆时就需要自己补。常见的一组字段如下guestOS darwin20 smc.version 0 board-id.reflectHost TRUE hw.model.reflectHost TRUE serialNumber.reflectHost FALSE smbios.reflectHost TRUEguestOS决定 vmware-vmx 用哪套 Darwin 设备模型。macOS 11 对应 darwin20macOS 12 对应 darwin21对应关系要准确写错高版本系统会引导失败。smc.version是踩坑率最高的字段。macOS 引导依赖虚拟 SMC 的模拟状态取值为 0 时补丁后的 vmware-vmx 会走兼容路径如果缺失很多系统会卡在引导早期连安装界面都到不了。board-id.reflectHost和hw.model.reflectHost把宿主的硬件标识透传给客户机让 macOS 的配置流程更容易通过。serialNumber.reflectHost一般设成 FALSE序列号保持虚拟机自身标识避免多台克隆虚拟机出现硬件信息冲突。smbios.reflectHost让 DMI 信息更接近真实硬件配合前几个字段可以避免部分系统版本在引导中期反复重启。darwin 版本对应不需要死记给一个查法在已经能开的 mac 虚拟机里执行uname -r拿到内核主版本号后对照| 系统版本 | guestOS 常见取值 | | macOS 10.15 | darwin19 | | macOS 11 | darwin20 | | macOS 12 | darwin21 | | macOS 13 | darwin22 | | macOS 14 | darwin23 |不过只要向导里能选对应系统版本直接让向导生成 vmx 是最省事的手写字段只在模板克隆和迁移场景才需要。顺便说一句批量克隆时建议先确认模板 vmx 已包含上述字段再克隆否则克隆出来的机器可能只有 guestOS 是 darwin其他关键字段缺失全部无法引导排查起来非常累。4.3 CPU、内存与图形加速的常用配法内存方面最低给 4GBmacOS 12 及以上建议 8GB 起。低于 4GB 时安装阶段就可能出现进度条卡死和补丁没关系就是内存不足。CPU 核心数不要超过宿主逻辑线程数常规 2 到 4 核足够。虚拟化设置里记得开启“虚拟化 Intel VT-x/EPT”或 AMD-V/RVImacOS 对虚拟化支持的敏感度比 Windows 高不少。磁盘控制器优先选 NVMeSATA 也能用但 NVMe 在 mac 客户机里的识别更干净IO 表现也更接近真机。图形方面打开“加速 3D 图形”并把显存调到 1GB 或 2GB否则桌面动画会明显掉帧。不要手动把虚拟显卡型号改成真实 mac 型号虚拟显卡就让它走虚拟显卡驱动。网络适配器也有讲究。mac 客户机对虚拟网卡驱动的内置支持有限e1000e 通常开箱即用vmxnet3 在部分系统里需要额外装驱动才能识别。稳妥起见第一次安装用 e1000e如果后续做 CI 或传输大文件对网络性能敏感再在装好系统、装好 VMware Tools 之后切换 vmxnet3。5. Unlocker 高频问题排查5 个从装不上到开不了机的坑5.1 双击脚本一闪而过补丁没有生效现象运行脚本后没有输出或窗口一秒消失重启 VMware 仍然没有 macOS 选项。原因Windows 权限不足脚本没权限写 Program Files 下的 vmware-vmx或者解压路径含空格、中文脚本拼接路径时出错实时防护拦截了脚本进程。解决右键“命令提示符”选择“以管理员身份运行”先cd /d C:\tools\unlocker21再执行win-install.cmd。工作目录与脚本目录保持一致路径保持纯英文无空格。执行前临时关闭杀毒实时保护或者右键脚本文件勾选“解除锁定”。脚本正常时会在窗口停留并打印 backup 和 patching 字样而不是一闪而过。5.2 解锁后 macOS 选项依然是灰色现象向导里出现了 macOS 列表但选择后“下一步”按钮置灰或者只有几个旧版本可选。原因当前虚拟机的硬件兼容版本超出补丁能识别的范围或者 2.1.1 这个版本太老对新版 vmware-vmx 的特征段匹配不上。解决新建虚拟机第一步把硬件兼容版本切到 15.x 再试。如果目标系统版本不在列表里选最接近的高版本比如想装 macOS 13先选 macOS 12装好后多数情况能正常引导。如果两个办法都无效说明补丁与当前宿主版本不兼容需要换更新版 unlocker。这是版本匹配问题不是操作问题别反复重试消耗时间。5.3 装系统时卡在 macOS 引导界面或进度条中途反复重启现象macOS 安装开始后虚拟机到引导界面就停住或自动重启进度条永远走不完。原因SMC 参数没有正确写入固件类型被设成了 BIOS内存低于最低要求补丁只生效了一半。解决确认虚拟机设置里的固件类型是 EFImacOS 不支持 BIOS 引导检查 vmx 里是否有smc.version 0内存调到 8GB硬盘控制器换成 NVMe 再试。还有一个容易忽略的原因VMware 的“加密虚拟机”选项会干扰 macOS 引导把它关掉。如果 vmware.log 里一直出现 SMC reset 字样优先检查 smc.version而不是重装系统。5.4 VMware 升级后解锁失效现象升级 Workstation 版本后原来能开的 mac 虚拟机全体弹“不受支持”。原因升级包重新覆盖了 vmware-vmx 可执行文件补丁被还原成原始状态。解决重跑解锁脚本即可。建议养成固定顺序先备份当前 vmware-vmx 原始文件再升级 VMware升级完成后重跑 unlocker 安装脚本最后打开一台测试虚拟机验证。不要反过来先补丁再升级等于白打。升级后不确定补丁是否还在最快的判断办法是哈希对比。升级前后同一路径的 vmware-vmx 哈希如果变了说明补丁被覆盖需要重新执行补丁脚本。这套方法比等报错更主动。5.5 杀毒软件把补丁后的虚拟机文件当病毒清除现象启动虚拟机时提示找不到 vmware-vmx.exe打开杀毒软件隔离区里面躺着一个同名文件。原因vmware-vmx.exe 被修改后与杀毒软件特征库里的原版不一致被判定为高风险篡改。解决先从隔离区恢复文件再把 VMware 安装目录和 unlocker 解压目录加入白名单最后以管理员身份重跑一遍补丁。如果恢复失败用 VMware 安装程序的“修复”功能还原原始文件再重新打补丁。注意不要先跑 uninstall 再跑 install那样可能把被隔离后残缺的文件当成“原始文件”备份后续恢复时更麻烦。6. 从解锁到可持续用日志验证与固定流程避免反复翻车6.1 vmware.log 里藏着最终判决补丁成功与否向导下拉框说了算但“能选 macOS”不等于“能稳定启动”。我每台 mac 虚拟机安装时都会在虚拟机所在目录开一个终端实时看日志# 在虚拟机所在目录执行 tail -f vmware.log正常引导的日志里与 SMC 相关的状态会被客户机接受日志段落是连续的、没有中断报错。如果看到 SMC 相关的 reset 或 error说明虚拟 SMC 模拟没对上别硬重启回到第 5 章逐条排查。Windows 下也可以用 PowerShell 的 Select-String 在 vmx 所在目录检索关键字效果一样。日志还有一个用途判断补丁之后虚拟机到底卡在哪一步。引导早期的问题多半在固件和 SMC引导中后期的问题多半在磁盘控制器或显卡驱动。看日志定位比重装系统有效率得多。6.2 把解锁流程固化成一套固定动作我会在每台宿主机上放一个 tools 目录里面只放三样东西unlocker 解压包、升级前备份的 vmware-vmx 原文件、记录 .vmx 关键字段的说明卡。所有 mac 虚拟机维护都按固定顺序走改 vmx 前先备份 → 运行补丁 → 用一台探针虚拟机开机验证 → 再打开业务虚拟机。流程走顺之后问题基本集中在版本不匹配这一类操作层面反而很少翻车。我的习惯是每次手工改过 vmx就把改动过的字段复制到同级 notes.txt并写明当时用的 VMware 版本和 unlocker 版本。下次升级、迁移、换机器只要按 notes 里的版本组合复现不依赖记忆。这个习惯帮我省掉了大量重复排查时间希望你也能少踩几个坑。本文还有配套的精品资源点击获取