Ubuntu 24.04 是长期支持版本里改动比较激进的一代内核默认上了 6.8glibc 也升到了 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 /CNVMware 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)签完之后把公钥注册进 MOKsudo 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仅主机和vmnet8NAT两个虚拟网卡。用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安装时提示找不到libaio124.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 安装难点从来不在安装命令本身而在安装之前的准备和安装之后的维护。把依赖装齐、把内核和头文件对齐、把安全启动的状态搞清楚剩下的就是按部就班。内核更新后的重编更是要当成日常维护的一部分而不是出了问题才想起来的事。