Ubuntu 24.04 是长期支持版本里改动比较激进的一代，内核默认上了 6.8，glibc 也升到了 2.39，很多老牌闭源软件在这套组合上都会出现编译模块失败、依赖缺失或者界面渲染异常的问题。VMware Workstation 17.5.1 恰好是官方明确适配 24.04 的一个版本，但"官方适配"和"装完就能用"之间还隔着一段距离。我前后在三台不同配置的机器上装过这个组合，踩过的坑从内核头文件缺失到 vmmon 模块编译报错，再到 Wayland 会话下的黑屏，基本把能遇到的都遇了一遍。这篇内容就是把这些过程完整摊开，从准备工作、安装包获取、依赖处理、模块编译、首次启动配置一直到常见故障排查，给出一套可以直接照着走的流程。适合刚接触 Linux 桌面、需要在本地跑虚拟机做测试环境的开发者，也适合从旧版本升级上来、发现模块加载失败的老用户。全文会围绕"为什么这么做"展开，而不是只丢一串命令，因为这套东西一旦出问题，光看命令是修不好的。
1. 装之前先想清楚：为什么是 17.5.1 而不是别的版本
1.1 版本选择背后的兼容性逻辑
很多人装虚拟机软件的习惯是"下最新版"，但在 Ubuntu 24.04 这个时间点上，版本选择其实是个需要动脑子的事。VMware Workstation 在 17.5.1 之前的几个小版本，对 6.8 内核的支持是不完整的，典型表现就是安装脚本跑完看着一切正常，但vmmon和vmnet两个内核模块编译不过去，启动虚拟机时直接报"无法连接到虚拟机监控程序"。而 17.5.1 是官方在发布说明里点名支持 Ubuntu 24.04 的版本，它内置的模块源码针对 6.8 内核做了适配，编译成功率明显高出一截。
这里有个容易被忽略的点：内核模块的编译不是"一次编译永久有效"的。Ubuntu 24.04 会持续推送内核更新，每次内核小版本变动，vmmon和vmnet都需要重新编译。17.5.1 的源码树对 6.8 系列内核的适配比较完整，后续 6.8.x 的小版本更新基本都能顺利重编，而更老的版本在遇到 6.8.0-xx 这类更新时经常直接编译中断。所以选 17.5.1 不只是"能用"，更是"后续维护成本低"。
另一个维度是桌面环境。Ubuntu 24.04 默认使用 GNOME 46，并且 Wayland 是默认会话。VMware Workstation 17.5.1 对 Wayland 的支持比早期版本好很多，但依然存在一些渲染上的小毛病，比如窗口缩放时偶尔闪烁、多显示器切换后虚拟机窗口位置错乱。这些不是致命问题，但知道它们的存在能让你在遇到时不至于怀疑自己装错了。
1.2 硬件与系统前提的自查清单
在动手之前，有几项前提必须确认，否则后面会白忙活。第一是 CPU 虚拟化支持，Intel 平台看vmx标志，AMD 平台看svm标志，用grep -E 'vmx|svm' /proc/cpuinfo能直接看到。如果这条命令没有任何输出，说明 BIOS/UEFI 里的虚拟化开关没打开，需要进固件设置里开启。第二是内存，宿主机至少留 8GB，因为虚拟机本身要分走一部分，Ubuntu 桌面本身也要吃 2GB 左右，低于这个数跑起来会很卡。
第三是磁盘空间。VMware Workstation 安装包解压后加上模块编译产物，大概占 1GB 出头，但虚拟机磁盘文件才是大头。建议系统盘至少留 30GB 空闲，如果打算跑多个虚拟机，最好单独挂一块盘或者把虚拟机目录放到大容量分区上。第四是安全启动状态，这个在后面的模块签名环节会详细讲，但提前用mokutil --sb-state看一眼能省不少事。如果显示SecureBoot enabled，那模块编译完还需要走签名流程，否则加载会被拒绝。
还有一项是内核头文件。VMware 的内核模块编译依赖当前运行内核对应的头文件包，Ubuntu 24.04 上这个包叫linux-headers-$(uname -r)。很多人装完系统后内核已经更新过，但头文件没跟着装，导致编译时找不到Module.symvers或者autoconf.h。提前用dpkg -l | grep linux-headers确认一下，没有就补上，比事后排查省心得多。
2. 安装包获取与依赖补齐：别急着双击那个 bundle 文件
2.1 安装包的来源与校验
VMware Workstation 的 Linux 版本以.bundle文件形式分发，这个文件本质是个自带运行环境的安装脚本。获取渠道上，建议直接从官方下载页面拿对应版本，文件名类似VMware-Workstation-Full-17.5.1-xxxxxxxx.x86_64.bundle。下载完成后先做一次完整性校验，官方页面通常会给出 SHA256 值，用sha256sum对一下。这一步看着多余，但安装包动辄几百 MB，下载中断导致文件损坏的情况并不罕见，而损坏的 bundle 在运行时给出的报错往往很含糊，容易误导排查方向。
拿到文件后给它加执行权限：chmod +x VMware-Workstation-Full-17.5.1-*.bundle。这里有个细节，bundle 文件不要放在带空格或者中文的路径下，安装脚本内部有些地方对路径处理不够健壮，放在/tmp或者用户主目录下的纯英文路径最稳妥。
2.2 编译依赖的完整清单
VMware Workstation 在 Linux 上安装时，需要现场编译内核模块，所以编译工具链必须齐全。Ubuntu 24.04 上需要装的包包括build-essential、linux-headers-$(uname -r)，以及几个图形和网络相关的运行库。完整的安装命令是这样：
sudo apt update sudo apt install -y build-essential linux-headers-$(uname -r) \ libaio1t64 libglib2.0-0t64 libgtk-3-0t64 libsm6 libxrender1 \ libxext6 libxi6 libxtst6 libncurses6 libnss3 libpci3这里要特别说明libaio1t64这个包。Ubuntu 24.04 做了一次 time_t 相关的 ABI 迁移，很多老库的包名从libaio1变成了libaio1t64，如果照着旧教程装libaio1会提示找不到包。同理libglib2.0-0t64和libgtk-3-0t64也是这个命名规则。这是 24.04 上一个很典型的坑，网上大量 22.04 时代的教程在这里会直接卡住。
build-essential提供的是 gcc、make、dpkg-dev 这一套，模块编译全靠它。linux-headers前面提过，是编译的硬前提。图形库那几个是 VMware 的图形界面依赖，缺了会导致安装程序启动时报error while loading shared libraries。libpci3用于硬件信息探测，libnss3涉及网络相关的加密功能，都别漏。
2.3 一个容易被忽略的前置动作
在正式跑安装脚本之前，建议先把系统更新到最新：sudo apt upgrade -y。原因在于内核头文件和运行内核必须严格对应，如果系统里有待安装的内核更新，装完头文件后重启，内核版本变了，头文件又对不上了。先把更新做完、重启一次，确认uname -r和已安装的头文件版本一致，再开始装 VMware，能避免一大类"编译到一半失败"的问题。
确认方法很简单：uname -r看当前内核，ls /usr/src/看已安装的头文件目录，两者应该能对上。如果对不上，sudo apt install linux-headers-$(uname -r)补装即可。
3. 安装过程与内核模块编译：真正容易翻车的环节
3.1 安装脚本的执行与交互选项
依赖齐了之后，用sudo ./VMware-Workstation-Full-17.5.1-*.bundle启动安装。脚本会先解压再进入一个基于 ncurses 的文本界面，一路回车接受许可协议即可。中间会问安装路径，默认/usr/bin和/usr/lib/vmware就行，没必要改。整个安装过程大概两三分钟，期间会看到它在编译vmmon和vmnet模块，这一步的输出信息很关键，如果出现Unable to build kernel module之类的字样，说明编译失败了，后面会专门讲怎么处理。
安装完成后，脚本会提示是否运行vmware-modconfig --console --install-all来配置模块。如果安装阶段模块已经编译成功，这一步通常也能过。但要注意，安装脚本里的模块编译和vmware-modconfig是两套逻辑，前者在安装时跑一次，后者是后续手动重编的入口。两者都可能因为内核头文件或者签名问题失败，报错信息大同小异。
3.2 vmmon 与 vmnet 编译失败的典型原因
模块编译失败是这套组合里最高频的问题，没有之一。表现是安装脚本末尾报错，或者启动 VMware 时弹窗提示"Before you can run VMware, several modules must be compiled and loaded into the running kernel"。点"Install"之后又是一轮失败。根因通常集中在三个方向。
第一个方向是内核头文件缺失或版本不匹配。前面强调过，uname -r和/usr/src/linux-headers-*必须一致。如果不一致，编译时会在找include/generated/autoconf.h这一步失败。修复就是补装对应版本的头文件，然后重新跑sudo vmware-modconfig --console --install-all。
第二个方向是 gcc 版本问题。Ubuntu 24.04 默认的 gcc 是 13.x，而某些内核头文件里的代码对高版本 gcc 的警告处理比较严格，可能因为-Werror把警告当错误处理导致编译中断。这种情况的报错里通常能看到error:字样紧跟某个警告。解决办法是看具体报错定位到源文件，但更省事的做法是确认内核头文件本身是否完整，因为绝大多数情况下问题不在 gcc 而在头文件。
第三个方向是安全启动。如果mokutil --sb-state显示SecureBoot enabled，那么编译出来的模块即使成功，加载时也会被内核拒绝，因为模块没有签名。这时候vmware-modconfig会报Failed to load module vmmon之类的错误。处理方式有两种：一是进固件设置关掉安全启动，二是给模块签名并注册 MOK。前者简单粗暴但降低了一层启动安全防护，后者规范但步骤多一些。如果这台机器只是个人开发用，关掉安全启动是可接受的取舍；如果是共享设备或者有合规要求，走签名流程更合适。
3.3 安全启动下的模块签名实操
走签名路线的话，流程是这样的。先确认系统里有mokutil和openssl，没有就sudo apt install mokutil openssl。然后生成一对密钥：
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=VMware Module Signing/"这会在当前目录生成MOK.priv和MOK.der。接着用这对密钥给编译好的模块签名，模块文件位置在/usr/lib/vmware/modules/下面，具体路径随版本略有差异，可以用find /usr/lib/vmware -name 'vmmon.ko'定位。签名命令是：
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)签完之后把公钥注册进 MOK：sudo mokutil --import MOK.der，会要求设置一个一次性密码。重启时会出现一个蓝色的 MOK 管理界面，选"Enroll MOK"，输入刚才设的密码，确认导入。重启进系统后modinfo vmmon应该能看到signer字段，说明签名生效。
这里有个实操心得：签名用的密钥文件别随手删，后续内核更新导致模块重编后，新模块还需要重新签名。把MOK.priv和MOK.der放到一个固定目录（比如/root/module-signing/），权限设成 600，后续重签直接复用，省得每次重新生成。
4. 首次启动与基础配置：装完不等于能用
4.1 首次启动的向导与许可
模块加载成功后，从应用菜单或者终端vmware命令启动。第一次启动会弹许可协议，接受后进入主界面。如果之前装过旧版本，可能会提示是否保留旧配置，按需选择即可。主界面出来后先别急着建虚拟机，有几个基础设置值得先调。
首选项里的"内存"部分，建议把"预留内存"相关的选项确认一下。VMware 默认会根据宿主机内存动态分配，但在内存紧张的机器上，虚拟机运行时可能出现宿主机卡顿。如果宿主机只有 8GB，建议在虚拟机设置里把内存固定在一个合理值（比如 2GB 到 4GB），而不是让它动态膨胀。
"更新"选项卡里，建议关掉自动检查更新。原因很实际：自动更新可能在某个时间点把版本升到一个对当前内核适配不佳的版本，导致模块编译失败。手动控制更新节奏，在确认新版本适配当前内核后再升，更稳妥。
4.2 网络模式的选择与 vmnet 配置
VMware 提供桥接、NAT、仅主机三种主要网络模式。桥接模式下虚拟机会直接出现在宿主机所在的局域网里，获取独立 IP，适合需要被局域网其他设备访问的场景。NAT 模式下虚拟机通过宿主机转发上网，对外不可见，适合只需要上网、不需要被访问的测试环境。仅主机模式则完全隔离，适合做纯本地实验。
Ubuntu 24.04 上vmnet模块加载后，会创建vmnet1（仅主机）和vmnet8（NAT）两个虚拟网卡。用ip addr能看到它们。如果看不到，说明vmnet模块没加载成功，回到上一节排查。NAT 模式下如果虚拟机拿不到 IP，常见原因是宿主机上的vmware-networks服务没起来，用sudo systemctl status vmware-networks看一下，没起来就sudo systemctl start vmware-networks。
这里有个细节值得注意：Ubuntu 24.04 的 NetworkManager 对虚拟网卡的管理有时会"多管闲事"，把vmnet1和vmnet8标记为未托管或者尝试自动配置。如果发现虚拟机网络异常，可以检查/etc/NetworkManager/conf.d/下是否有针对vmnet的排除配置。标准做法是加一个配置文件，把vmnet*接口排除在 NetworkManager 管理之外，交给 VMware 自己的网络服务处理。
4.3 Wayland 会话下的显示问题处理
Ubuntu 24.04 默认 Wayland 会话，VMware Workstation 17.5.1 在 Wayland 下能跑，但有几个已知的小毛病。一是虚拟机窗口在全屏和窗口模式切换时偶尔出现黑屏或者花屏，二是高分屏下缩放比例可能不对，界面元素偏小或偏大。前者通常切换一下窗口模式能恢复，后者需要在 VMware 首选项里手动调缩放，或者在 GNOME 的显示设置里调整分数缩放。
如果这些问题影响到正常使用，一个务实的做法是在登录界面切换到 Xorg 会话。GNOME 登录界面点用户名后，右下角有个齿轮图标，选"Ubuntu on Xorg"再登录。Xorg 会话下 VMware 的兼容性明显更好，代价是失去 Wayland 的一些新特性。对于以虚拟机为主要工作场景的机器，这个取舍是值得的。
5. 内核更新后的模块重编：一个必须养成的习惯
5.1 为什么每次内核更新都要重编
前面提过，vmmon和vmnet是针对特定内核版本编译的。Ubuntu 24.04 的内核更新频率不低，安全补丁和小版本迭代都会触发。内核一换，旧模块的 vermagic 就对不上，加载时直接报version magic ... should be ...之类的错误。表现就是某次系统更新重启后，VMware 突然打不开了，弹窗要求重新编译模块。
这不是故障，是正常机制。理解这一点很重要，否则容易误以为是安装出了问题而重装一遍，白白浪费时间。正确的应对是养成习惯：每次内核更新并重启后，先跑一次sudo vmware-modconfig --console --install-all，让它针对新内核重编模块。如果开了安全启动，重编后还要重新签名，这就是前面建议保留签名密钥的原因。
5.2 自动化重编的可行方案
手动重编虽然简单，但容易忘。一个可行的自动化思路是用 systemd 服务或者内核的 DKMS 框架。VMware 官方没有提供 DKMS 配置，但社区有现成的方案：把vmmon和vmnet的源码目录注册到 DKMS 里，内核更新时 DKMS 会自动触发重编。具体做法是把/usr/lib/vmware/modules/source/下的vmmon.tar和vmnet.tar解压，写一个dkms.conf，然后用dkms add注册。
不过这套方案在 17.5.1 上需要一些调整，因为源码目录结构和 DKMS 期望的布局不完全一致。对于不想折腾的人，更简单的办法是写一个 systemd oneshot 服务，在multi-user.target之后执行vmware-modconfig --console --install-all，失败也不阻塞启动。这样每次开机自动尝试重编，内核没变时它检测到模块已存在会快速跳过，内核变了就自动重编。这个方案的好处是简单可靠，坏处是开机时多花几秒。
5.3 重编失败时的回退思路
万一某次内核更新后重编失败，而你又急需用虚拟机，有个临时的回退办法：在 GRUB 启动菜单里选旧内核启动。Ubuntu 默认保留最近几个内核版本，开机时按 Esc 或 Shift 进 GRUB 菜单，选上一个能用的内核，模块就能正常加载。这能给你争取时间去排查新内核下的编译问题，而不是被卡死。
排查新内核编译失败时，重点看vmware-modconfig的完整输出，把报错行贴出来搜。常见的新内核适配问题包括：内核 API 变动导致函数签名不匹配、头文件路径调整、编译器警告升级为错误。这类问题通常等 VMware 发布新版本或者社区给出补丁就能解决，临时用旧内核顶着是合理的过渡方案。
6. 常见故障的排查链路与经验总结
6.1 从现象到根因的排查顺序
遇到 VMware 起不来，别急着重装，按下面的顺序排查能覆盖绝大多数情况。第一步看模块状态：lsmod | grep -E 'vmmon|vmnet'，两个模块都在说明加载没问题，问题在别处；缺了哪个就针对哪个查。第二步看模块加载报错：sudo modprobe vmmon手动加载，报错信息会直接指向原因，是签名问题、版本不匹配还是文件缺失，一目了然。第三步看编译日志：sudo vmware-modconfig --console --install-all重跑一遍，把完整输出留下来，编译错误的具体行号和原因都在里面。
这个顺序的逻辑是从"结果"往"原因"倒推。模块没加载是结果，加载失败的原因是签名或版本，编译失败的原因在日志里。按这个链路走，比盲目搜报错关键词高效得多。
6.2 几个高频问题的对照表
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 启动提示模块需编译，点安装后失败 | 内核头文件缺失或版本不匹配 | 确认uname -r与头文件版本一致，补装后重编 |
| 模块编译成功但加载被拒 | 安全启动开启且模块未签名 | 关闭安全启动或走 MOK 签名流程 |
| 虚拟机无法上网（NAT 模式） | vmware-networks服务未运行 | systemctl start vmware-networks |
| 窗口黑屏或花屏 | Wayland 会话兼容性问题 | 切换到 Xorg 会话 |
| 内核更新后突然打不开 | 模块未针对新内核重编 | 跑vmware-modconfig --console --install-all |
安装时提示找不到libaio1 | 24.04 包名变更为libaio1t64 | 改用libaio1t64等新包名 |
这张表里的每一条都是实际遇到过的，其中"包名变更"和"内核更新后重编"这两条在 24.04 上出现频率最高。前者是因为 24.04 的 ABI 迁移，后者是因为内核更新节奏。把这两条记牢，能省掉大半的排查时间。
6.3 一些不那么显然的经验
第一个经验是关于安装顺序的。有些人习惯先装 VMware 再装编译依赖，结果安装脚本在编译模块那一步失败，然后补装依赖再重跑安装脚本。这样虽然也能成，但安装脚本的模块编译逻辑有时不会因为依赖补齐而重新触发，需要手动跑vmware-modconfig。所以依赖一定要在跑 bundle 之前装齐，顺序别反。
第二个经验是关于磁盘空间的隐性占用。VMware 的虚拟机默认使用稀疏磁盘，看起来占用不大，但随着使用会逐渐膨胀。如果宿主机磁盘紧张，建议在虚拟机设置里开启"预分配磁盘空间"或者定期用vmware-vdiskmanager做碎片整理和压缩。这个工具在/usr/bin/下，用法是vmware-vdiskmanager -k 磁盘文件路径，能把稀疏磁盘里未使用的空间释放回宿主机。
第三个经验是关于快照的管理。快照很方便，但快照链过长会显著拖慢虚拟机性能，而且占用大量磁盘。建议快照只用于短期回滚点，用完及时删除或者合并。长期的状态保存应该用克隆而不是快照。这个习惯在跑测试环境时尤其重要，否则几个月下来虚拟机慢得没法用。
第四个经验是关于共享文件夹的。VMware 的共享文件夹功能在 Linux 宿主机上依赖open-vm-tools，但这个是装在客户机里的，宿主机这边只需要在虚拟机设置里配好路径。如果客户机是 Linux，装open-vm-tools和open-vm-tools-desktop；如果是 Windows，装 VMware Tools。共享文件夹在 Wayland 下偶尔有权限问题，表现为客户机里能看到目录但读写失败，这时候检查一下宿主机上共享目录的权限，确保运行 VMware 的用户对该目录有读写权限。
这套组合装下来，顺利的话半小时内能跑起第一台虚拟机，不顺利的话可能在模块编译上卡一两个小时。区别往往不在操作本身，而在于对"为什么会失败"的理解。把内核版本、头文件、安全启动这三者的关系理清楚，大部分问题都能自己定位。我在几台机器上反复装过之后最大的体会是：Ubuntu 24.04 上的 VMware 安装，难点从来不在安装命令本身，而在安装之前的准备和安装之后的维护。把依赖装齐、把内核和头文件对齐、把安全启动的状态搞清楚，剩下的就是按部就班。内核更新后的重编更是要当成日常维护的一部分，而不是出了问题才想起来的事。
