1. 为什么要在 Ubuntu 24.04 上折腾 VMware Workstation 17.5.1
在 Ubuntu 24.04 LTS 上跑 VMware Workstation 17.5.1，这件事听起来像是“老派虚拟化玩家”的日常操作，但真正动手过的人都知道，这一路并不平坦。Ubuntu 24.04 换上了 6.8 内核、默认启用了更严格的 Secure Boot 策略、把 OpenSSL 升到了 3.x 分支，还把 GCC 默认版本推到了 13，这一连串变化叠加起来，直接让 VMware Workstation 17.5.1 的官方安装包在“开箱即用”这件事上翻了车。我前后在三台不同配置的机器上装过这个组合，踩过的坑足够写满一页纸，所以这篇就把整个流程、原理和避坑经验一次性讲透。
先说清楚这个组合到底能干什么。VMware Workstation 17.5.1 是桌面级虚拟化软件，能在 Linux 宿主机上创建、运行 Windows、Linux、BSD 等多套虚拟机，支持快照、克隆、虚拟网络编辑、USB 设备直通、共享文件夹等一整套生产力功能。对于需要在本机跑多系统测试、做开发环境隔离、复现客户现场环境的人来说，它比纯命令行的 KVM 方案更直观，比云端虚拟机更省钱也更可控。而 Ubuntu 24.04 作为当前主流的长期支持版本，稳定性和软件生态都到位，两者结合是很多开发者和运维人员的真实需求。
适合谁来参考这篇内容？如果你是有一定 Linux 命令行基础、知道sudo怎么用、能看懂apt和dkms输出信息的开发者，那这篇基本可以照着抄。如果你是完全的 Linux 新手，也不用慌，我会把每一步的命令和预期输出都写清楚，遇到报错怎么判断、怎么处理也会一并说明。核心关键词就三个：Ubuntu 24.04 安装 VMware Workstation 17.5.1、内核模块编译、Secure Boot 签名，这三个词贯穿全文，理解了它们，整个安装过程就没有黑盒。
需要提前说明的是，VMware Workstation 17.5.1 这个版本号不是随便挑的。17.5.x 系列是官方针对较新内核做过适配的版本，相比 17.0.x 在老内核上更稳，但面对 6.8 内核仍然需要打补丁。这也是为什么很多人直接下载最新安装包却装不上的根本原因——安装包里的内核模块源码还没跟上 6.8 内核的 API 变化。理解这一点，后面的补丁操作你就不会觉得是“玄学”了。
2. 安装前的整体设计与环境准备
2.1 方案选型：为什么是官方 bundle 而不是 apt 源
在 Ubuntu 上装 VMware Workstation，市面上流传着几种路子：一是直接用官方下载的.bundle安装包，二是找第三方维护的 apt 源，三是用vmware-installer配合离线包。我实测下来，官方 bundle 是唯一可靠的选择。原因很直接：第三方 apt 源更新滞后，经常出现源里的版本和内核模块不匹配的情况，而且一旦源维护者停更，你就卡在一个装不上也卸不干净的尴尬状态。官方 bundle 虽然安装时需要手动处理内核模块，但它的卸载干净、版本可控、日志清晰，出问题好排查。
选 bundle 还有一个隐性好处：安装过程是透明的。它会调用vmware-modconfig去编译vmmon和vmnet两个内核模块，编译失败时你能看到完整的错误输出，而不是被 apt 包装成一句“安装失败”。对于需要理解底层机制的人来说，这份透明度比什么都重要。
2.2 硬件与系统前提检查
动手之前，先把几个硬性条件确认一遍，省得装到一半发现方向错了。下面这张表是我整理的检查清单，建议逐项过一遍：
| 检查项 | 要求 | 检查命令 | 不满足的后果 |
|---|---|---|---|
| CPU 虚拟化支持 | 开启 VT-x/AMD-V | grep -E "vmx|svm" /proc/cpuinfo | 虚拟机无法启动，报“此主机不支持虚拟化” |
| 内核版本 | 6.8.x（24.04 默认） | uname -r | 版本不符需额外适配 |
| 磁盘空间 | 至少 2GB 空闲 | df -h / | 安装中断，残留文件难清理 |
| 内存 | 建议 8GB 以上 | free -h | 跑虚拟机卡顿 |
| Secure Boot 状态 | 需确认开启或关闭 | mokutil --sb-state | 开启时模块需签名，否则加载失败 |
| 依赖工具 | gcc、make、内核头文件 | 见下文安装命令 | 模块编译直接失败 |
CPU 虚拟化这一项特别容易被忽略。有些笔记本出厂默认在 BIOS 里关掉了 VT-x，你在系统里怎么装都没用，虚拟机一开就报错。grep那条命令如果有输出（vmx对应 Intel，svm对应 AMD），说明虚拟化已开启；如果没输出，就得进 BIOS 打开。这个坑我在一台二手工作站上踩过，折腾了半天软件，最后发现是 BIOS 设置问题。
2.3 依赖环境的完整安装
Ubuntu 24.04 的最小安装镜像里不带编译工具链，而 VMware 的内核模块必须现场编译，所以依赖得先补齐。下面这组命令是我验证过的最小集合：
sudo apt update sudo apt install -y build-essential linux-headers-$(uname -r) \ gcc-12 g++-12 make dkms libaio1 libglib2.0-0 \ libgtk-3-0 libncurses6 libnss3 libpango-1.0-0 \ libsecret-1-0 libx11-6 libxext6 libxi6 libxtst6这里有几个细节值得展开。linux-headers-$(uname -r)必须和当前运行内核严格对应，如果你装完头文件后又升级了内核但没重启，头文件版本和运行内核就对不上了，编译必然失败。gcc-12是特意指定的，因为 Ubuntu 24.04 默认的 GCC 13 对 VMware 17.5.1 的部分源码兼容性不好，会报一些奇怪的警告甚至错误，降到 12 能规避大部分问题。libaio1是异步 IO 库，虚拟机磁盘性能依赖它；libglib2.0-0和 GTK 系列是图形界面依赖，缺了会打不开 VMware 的窗口。
提示：如果你之前装过旧版 VMware 且没卸干净，先执行
sudo vmware-installer -u vmware-workstation彻底卸载，再清理/etc/vmware、/usr/lib/vmware残留目录，否则新版安装可能因为旧配置冲突而失败。
3. 核心细节解析：内核模块与 Secure Boot 的两道坎
3.1 vmmon 与 vmnet 模块到底在干什么
VMware Workstation 在 Linux 上不是纯用户态程序，它依赖两个内核模块：vmmon负责 CPU 虚拟化的底层调度和虚拟机监控，vmnet负责虚拟网络设备（NAT、桥接、仅主机网络）。这两个模块是闭源的，以源码形式随安装包分发，安装时由vmware-modconfig调用本机编译器现场编译成.ko文件。这就是为什么每次内核升级后，VMware 都可能需要重新编译模块——内核 API 变了，旧模块加载不上。
理解这一点，你就能明白为什么 17.5.1 在 6.8 内核上会翻车。6.8 内核改动了几个内部结构体的定义，比如vm_operations_struct的字段调整、kernel_read系列函数签名变化，而 17.5.1 自带的模块源码还是按老 API 写的，编译时直接报“结构体没有该成员”之类的错误。解决办法不是等官方更新，而是给源码打补丁——社区里已经有成熟的补丁方案，核心思路是把旧 API 调用替换成新内核对应的写法。
3.2 Secure Boot 开启时的签名难题
第二道坎是 Secure Boot。Ubuntu 24.04 默认在支持 UEFI 的机器上开启 Secure Boot，而 Secure Boot 只允许加载经过签名的内核模块。VMware 编译出来的vmmon.ko和vmnet.ko是本地编译的，没有签名，加载时会被内核拒绝，报错类似module verification failed: signature and/or required key missing。
处理这个问题的标准做法是用 MOK（Machine Owner Key）给模块签名。流程是：生成一对密钥，用mokutil把公钥注册进固件，重启时在 MOK 管理界面确认导入，然后用私钥给模块签名。这套流程听起来复杂，但每一步都有明确命令，照着做就行。另一种更省事的做法是进 BIOS 关掉 Secure Boot，但我不推荐——关掉会降低系统整体安全性，而且有些机器关掉后会影响其他功能的正常使用。签名方案虽然多几步，但一劳永逸，后续内核升级重新签名即可。
注意：MOK 注册过程中会要求你设置一个一次性密码，重启后在蓝色管理界面输入。这个界面是文本模式的，键盘布局可能和系统里不一致，密码里尽量别用特殊符号，纯字母数字最稳妥。
3.3 补丁方案的取舍逻辑
面对 6.8 内核的兼容问题，市面上有三种处理方式：一是等官方发新版，二是自己改源码，三是用社区维护的补丁集。第一种不可控，第二种对大多数人门槛太高，第三种是性价比最高的选择。社区补丁集通常针对特定内核版本维护，覆盖了vmmon和vmnet两个模块的常见编译错误，应用方式也简单，patch命令一跑就行。
选补丁时要注意版本匹配。补丁是针对特定 VMware 版本和内核版本组合写的，17.5.1 配 6.8 内核有对应的补丁分支，别拿 17.0.x 的补丁往 17.5.1 上套，否则会出现“补丁应用成功但编译报新错”的情况。我一般会先看补丁仓库的 README，确认它声明支持的内核范围，再决定用不用。
4. 实操过程：从下载到虚拟机跑起来
4.1 下载与校验安装包
官方安装包的下载地址在 VMware 官网的 Workstation 下载页，选 Linux 版本的.bundle文件，文件名类似VMware-Workstation-Full-17.5.1-23298084.x86_64.bundle。下载完先校验，别嫌麻烦，一个损坏的安装包能让你在编译阶段浪费一小时：
sha256sum VMware-Workstation-Full-17.5.1-23298084.x86_64.bundle把输出和官网公布的 SHA256 值对比，一致再继续。然后给执行权限：
chmod +x VMware-Workstation-Full-17.5.1-23298084.x86_64.bundle4.2 执行安装并观察模块编译
安装命令本身很简单：
sudo ./VMware-Workstation-Full-17.5.1-23298084.x86_64.bundle但真正的信息量在输出里。安装程序会先解包，然后调用vmware-modconfig --console --install-all去编译模块。如果这一步直接成功，说明你的环境很干净，可以跳到 4.4；如果报编译错误，别慌，这正是 6.8 内核的典型表现，继续往下走补丁流程。
安装过程中会提示接受许可协议、选择安装路径（默认/usr/lib/vmware）、是否创建桌面快捷方式等，按默认走即可。安装完成后先别急着启动，因为模块大概率没编译成功，启动会报“无法加载 vmmon 模块”。
4.3 打补丁并重新编译模块
补丁的获取方式这里不展开具体仓库地址，思路是找到对应 17.5.1 + 6.8 内核的补丁文件，下载到本地后按以下流程操作。先备份原始模块源码目录：
sudo cp -r /usr/lib/vmware/modules/source /usr/lib/vmware/modules/source.bak然后解压模块源码包，应用补丁：
cd /tmp tar -xf /usr/lib/vmware/modules/source/vmmon.tar tar -xf /usr/lib/vmware/modules/source/vmnet.tar # 将补丁文件放到 /tmp 下，假设名为 vmware-6.8.patch patch -p1 -d vmmon < vmware-6.8.patch patch -p1 -d vmnet < vmware-6.8.patch补丁应用成功后，把修改后的源码重新打包回.tar，覆盖原文件：
sudo tar -cf /usr/lib/vmware/modules/source/vmmon.tar -C /tmp vmmon sudo tar -cf /usr/lib/vmware/modules/source/vmnet.tar -C /tmp vmnet最后重新触发模块编译：
sudo vmware-modconfig --console --install-all这一步的输出要仔细看。如果看到Building vmmon module和Building vmnet module后面跟着Success，说明编译通过。如果还有报错，通常是补丁没打全或者 GCC 版本问题，把错误信息里的函数名和行号记下来，对照补丁内容排查。
4.4 Secure Boot 签名实操
模块编译成功后，如果 Secure Boot 是开启状态，还得签名。先生成密钥对：
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=VMware Local Signing/"把公钥注册进固件：
sudo mokutil --import MOK.der系统会要求设置一个密码，记住它。然后重启，在启动过程中会出现蓝色的 MOK 管理界面，选“Enroll MOK”，输入刚才的密码，确认导入。重启进系统后，给模块签名：
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmmon) sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmnet)签名完成后验证模块能否加载：
sudo modprobe vmmon sudo modprobe vmnet lsmod | grep vm如果lsmod能看到vmmon和vmnet，说明一切就绪。这时候启动 VMware Workstation，界面应该能正常打开，新建虚拟机的按钮也可用了。
4.5 首次启动与虚拟机创建验证
启动命令是vmware，或者从应用菜单里点图标。第一次启动可能会提示“内核模块已更新，需要重新编译”，这是正常的，点确认让它编译即可。然后新建一台测试虚拟机验证功能：选一个 Linux ISO，分配 2GB 内存、20GB 磁盘，启动看能否进入安装界面。如果虚拟机正常启动、网络能通、USB 设备能识别，说明整个安装链路彻底打通。
这里有个小技巧：新建虚拟机时网络模式先选 NAT，验证基础网络通不通；再切到桥接模式，验证vmnet模块的桥接功能。两种模式都正常，才算真正装好了。
5. 常见问题与排查技巧实录
5.1 编译报错速查表
下面这张表是我在实际操作中整理的高频报错和对应处理方式，覆盖了 90% 以上的场景：
| 报错关键词 | 根本原因 | 处理方式 |
|---|---|---|
implicit declaration of function 'kernel_read' | 6.8 内核函数签名变化 | 应用对应补丁，替换为新 API |
struct vm_operations_struct has no member named 'access' | 结构体字段调整 | 补丁中删除或替换该字段引用 |
error: too few arguments to function 'vm_insert_page' | 函数参数变化 | 补丁补充缺失参数 |
module verification failed | Secure Boot 未签名 | 走 MOK 签名流程 |
Unable to find the kernel headers | 头文件缺失或版本不符 | 重装linux-headers-$(uname -r) |
gcc: error: unrecognized command-line option | GCC 版本过高 | 切换update-alternatives到 gcc-12 |
vmnet1: no such device | vmnet 模块未加载 | modprobe vmnet并检查签名 |
5.2 三个最容易踩的坑
第一个坑：装完头文件没重启就编译。如果你在安装过程中系统自动升级了内核，uname -r显示的是新内核，但头文件可能还是旧的，或者反过来。编译前务必确认uname -r和/usr/src/linux-headers-*目录名一致，不一致就重启到对应内核再操作。
第二个坑：补丁打错目录层级。patch -p1里的-p1表示忽略路径的第一层，如果补丁文件里的路径结构和你的源码目录结构对不上，补丁会“应用成功”但实际改错了位置，编译时报一堆莫名其妙的错。判断方法是看patch输出里有没有Hunk #N FAILED，有就说明没打对，得调整-p参数。
第三个坑：签名后内核升级，模块又失效。这是最隐蔽的问题。内核一升级，旧的.ko文件路径变了，签名也失效了，VMware 启动时报模块加载失败。解决办法是每次内核升级后重新执行vmware-modconfig --console --install-all和签名命令。嫌麻烦的话可以写个脚本，把编译和签名串起来，内核升级后跑一次就行。
5.3 卸载与回滚的干净做法
万一装崩了想重来，卸载要彻底。先停服务：
sudo systemctl stop vmware sudo vmware-installer -u vmware-workstation然后手动清理残留：
sudo rm -rf /etc/vmware /usr/lib/vmware /var/lib/vmware /var/log/vmware sudo rm -f /etc/init.d/vmware /etc/rc*.d/*vmware*最后把之前注册的 MOK 密钥也考虑撤销（如果不再需要），用sudo mokutil --delete MOK.der并重启确认。清理干净后再装新版，能避免大量“配置文件冲突”类的诡异问题。
6. 装好之后：几个提升稳定性的实操心得
装完只是开始，日常用起来稳不稳，还取决于几个细节。第一，别在 VMware 运行时挂起或休眠宿主机，恢复后虚拟网络经常出问题，vmnet模块状态异常，重启 VMware 服务（sudo systemctl restart vmware）能救回来。第二，共享文件夹的性能不如原生挂载，大文件传输建议走网络或者直接挂载物理磁盘，共享文件夹适合小文件交换。第三，快照别开太多，每个快照都占磁盘，而且快照链太长会拖慢虚拟机启动，我一般控制在三个以内，用完及时合并。
还有一个容易被忽略的点：Ubuntu 24.04 的 AppArmor 默认策略有时会拦截 VMware 的某些操作，表现为虚拟机启动到一半卡住或者 USB 设备识别不了。排查时看dmesg | grep -i apparmor有没有拒绝记录，有的话给 VMware 相关可执行文件加例外规则，或者临时用sudo aa-complain切到宽容模式验证是不是 AppArmor 的问题。
最后分享一个我常用的验证脚本思路：把modprobe vmmon、modprobe vmnet、lsmod | grep vm、vmware --version这几条串成一个 shell 脚本，每次内核升级后跑一遍，输出全绿就说明环境健康，省得每次手动敲。这个习惯帮我省下了不少“虚拟机突然打不开”的排查时间。
