Linux离线安装VMware Workstation全攻略：依赖包收集与内核模块编译详解

1. 项目概述：为什么需要一份详尽的离线安装指南？

在Linux环境下部署VMware Workstation，对于很多从事开发、测试、运维或者安全研究的工程师来说，是搭建本地实验环境的常规操作。然而，一个经常被忽略但实际工作中频繁遇到的场景是：离线安装。你可能会在客户的内网服务器、没有互联网接入的研发测试机、或者出于安全策略限制的生产环境中遇到这个问题。网络上的教程大多默认你有一台能顺畅访问互联网的机器，步骤无非是下载、安装、激活。但当你真正面对一台“与世隔绝”的Linux主机时，会发现从依赖包缺失到许可证验证，每一步都可能成为拦路虎。

这份教程的目的，就是彻底解决这个问题。我将基于多年的系统部署经验，为你拆解在Linux系统上，如何在没有网络连接的情况下，完整、顺利地将VMware Workstation安装到位。这不仅仅是把安装包拷贝过去那么简单，它涉及到对Linux包管理机制的深入理解、对软件依赖关系的精确梳理，以及一系列绕过在线验证的实操技巧。无论你使用的是CentOS/RHEL、Ubuntu/Debian还是其他主流发行版，其核心思路是相通的。接下来，我会手把手带你走完整个流程，并重点分享那些容易踩坑的环节和我的独家解决心得。

2. 核心思路与准备工作：离线安装的本质是什么？

在开始动手之前，我们必须先理解“离线安装”在Linux语境下的真正含义。它不是一个独立的安装模式，而是将在线安装过程中所有需要从网络获取的资源，提前在另一台有网络的“跳板机”上准备好，然后完整地搬运到目标离线机上执行。

这个过程的核心可以分解为三个关键任务：

1. 获取完整的安装包：包括主程序Bundle包和对应的许可证密钥。
2. 解决系统依赖：这是离线安装最大的挑战。VMware Workstation依赖一系列系统库和内核模块，这些依赖不会全部包含在它的安装包里。
3. 处理内核相关组件：VMware需要编译和加载专属的内核模块（如vmmon,vmnet），这要求目标机的内核头文件版本必须与当前运行的内核严格一致。

因此，我们的准备工作需要围绕一台联网环境、且系统版本与目标机尽可能一致的“准备机”来展开。理想情况下，准备机与目标机是同一发行版的相同版本。如果做不到完全一致，比如目标机是CentOS 7.9，你至少要用一台CentOS 7.x的机器做准备，避免主要版本差异带来的库文件不兼容。

2.1 工具与材料清单

在开始之前，请确保你手头有以下资源：

• 一台可联网的Linux准备机：用于下载所有所需文件。系统版本尽量与目标机一致。
• 一个足够大的U盘或移动硬盘：用于将打包好的文件传输到离线机。如果网络隔离但物理可通，这是最直接的方式。
• 目标离线机的root权限：离线安装涉及系统级操作，必须拥有sudo或直接root权限。
• VMware Workstation for Linux 的离线Bundle安装包：你需要从VMware官网或其他可信渠道获取对应版本的安装文件，通常是类似VMware-Workstation-Full-17.5.0-22583795.x86_64.bundle这样的文件。请务必确认版本与你的系统架构（通常是x86_64）兼容。
• 有效的许可证密钥：准备好你的VMware Workstation许可证。

2.2 关键策略：依赖包收集方法

解决依赖是重中之重。这里我分享两种最实用的方法，推荐结合使用。

方法一：利用YUM/DNF的downloadonly插件（适用于RHEL/CentOS/Fedora）这是最干净、最推荐的方法。它允许你模拟安装过程，但只下载所需的RPM包而不实际安装。

# 1. 首先确保`yum-utils`已安装，它包含了`yumdownloader`工具 sudo yum install -y yum-utils # 2. 在准备机上，创建一个目录存放下载的依赖包 mkdir -p ~/vmware-offline-deps # 3. 使用yumdownloader下载VMware bundle安装包本身所需依赖（假设已放入当前目录） # 这里的关键是`--resolve`参数，它会自动下载所有依赖，`--destdir`指定下载目录 sudo yumdownloader --resolve --destdir=~/vmware-offline-deps ./VMware-Workstation-Full-*.bundle

执行后，所有相关的.rpm依赖包都会下载到~/vmware-offline-deps目录下。你需要将这些rpm包拷贝到目标机。

方法二：分析Bundle包并手动准备核心依赖（通用方法）有时候，方法一可能无法解析Bundle包的所有依赖。我们可以通过分析安装包或查阅文档，手动准备最关键、最常见的依赖。对于VMware Workstation，以下依赖在多数Linux发行版上都是必需的：

• 内核相关：kernel-headers,kernel-devel(版本必须与目标机uname -r输出完全一致)。
• 基础编译工具：gcc,make。
• 图形库与依赖：glibc,libgcc,libstdc++,libX11,libXtst,libXrender,libXrandr,mesa-libGL等。
• 其他：perl,which,net-tools。

对于Debian/Ubuntu系列，你需要准备对应的.deb包，可以使用apt-get download命令在准备机上下载。

注意：内核头文件（kernel-headers,kernel-devel）的版本必须与目标机正在运行的内核版本精确匹配。在目标机上运行uname -r获取版本号，然后在准备机通过yum download kernel-devel-$(uname -r)或对应命令下载相同版本的包。这是后续编译VMware内核模块成败的关键。

3. 分步实操：离线安装全流程解析

假设我们现在已经在一台联网的CentOS 7准备机上完成了所有文件的收集，并将它们通过U盘拷贝到了目标离线机（也是CentOS 7）的/opt/vmware-offline目录下。目录结构如下：

/opt/vmware-offline/ ├── VMware-Workstation-Full-17.5.0-22583795.x86_64.bundle ├── deps/ # 存放所有下载的rpm依赖包 │ ├── kernel-devel-3.10.0-1160.el7.x86_64.rpm │ ├── gcc-4.8.5-44.el7.x86_64.rpm │ └── ... (其他依赖包) └── license.txt # 存放你的许可证密钥

3.1 第一步：离线安装系统依赖包

在目标离线机上，我们首先安装所有收集好的依赖包。进入存放依赖包的目录，使用rpm或yum的本地安装功能。

# 切换到依赖包目录 cd /opt/vmware-offline/deps # 使用rpm命令批量安装当前目录下所有rpm包，忽略依赖关系（因为我们已确保包齐全） # 但更好的方式是使用yum localinstall，它能更好地处理本地包的依赖关系 sudo yum localinstall *.rpm

yum localinstall会检查本地rpm包之间的依赖关系并依次安装，这比直接用rpm -ivh *.rpm更稳妥，能避免因安装顺序问题导致的依赖错误。

实操心得：在执行yum localinstall之前，可以先运行sudo yum clean all和sudo yum makecache（虽然离线，但清理元数据缓存有时能避免奇怪的问题）。如果遇到某个包提示“已安装更新版本”，可以加上--skip-broken参数跳过，但前提是你确认跳过不影响VMware核心功能。通常基础库如glibc等不建议跳过。

3.2 第二步：安装内核头文件与开发包

这是至关重要的一步。即使你在上一步安装了kernel-devel包，也需要验证其版本是否完全匹配。

# 1. 检查当前运行的内核版本 uname -r # 输出示例：3.10.0-1160.el7.x86_64 # 2. 检查已安装的内核头文件版本 rpm -qa | grep kernel-devel # 确认输出中包含与上面uname -r结果完全一致的版本号 # 3. 如果版本不一致，你需要找到对应版本的rpm包进行安装或降级。 # 假设我们已有正确的rpm包，强制安装（如果已存在错误版本） sudo rpm -ivh --force kernel-devel-3.10.0-1160.el7.x86_64.rpm

确保版本一致后，还需要确认内核头文件的位置是否正确。通常它们会在/usr/src/kernels/$(uname -r)/目录下。你可以快速检查一下：

ls -d /usr/src/kernels/$(uname -r)

如果这个目录存在且非空，说明内核头文件就位。

3.3 第三步：赋予Bundle安装包执行权限并运行

VMware的Bundle文件本质上是一个可执行的安装脚本。

# 1. 进入Bundle文件所在目录 cd /opt/vmware-offline # 2. 赋予执行权限 sudo chmod +x VMware-Workstation-Full-*.bundle # 3. 执行安装 # 使用--console参数可以在纯文本控制台界面安装，这在没有图形界面的服务器上尤其有用 sudo ./VMware-Workstation-Full-*.bundle --console

执行上述命令后，会进入一个基于文本的交互式安装界面。你需要：

1. 按回车键浏览最终用户许可协议。
2. 输入yes接受协议。
3. 选择安装路径（通常直接回车使用默认路径/usr/lib/vmware）。
4. 配置是否加入用户到vmware组（建议选择yes，方便非root用户使用）。
5. 等待安装程序运行。这里会遇到第一个关键点：安装程序会尝试编译VMware内核模块。由于我们已经提前安装了正确版本的内核头文件，这个过程应该会自动完成。如果失败，会给出明确错误信息。

3.4 第四步：处理内核模块编译与加载

如果安装过程中内核模块编译失败，或者安装后启动VMware提示内核模块问题，我们需要手动干预。

# 安装完成后，VMware提供了一个脚本用于编译和加载内核模块 # 进入VMware的安装目录下的bin文件夹 cd /usr/lib/vmware/bin # 运行vmware-modconfig工具，重新配置和编译模块 sudo ./vmware-modconfig --console --install-all

这个命令会重新调用编译器，针对当前内核编译vmmon,vmnet等模块。请密切关注命令输出，看是否有编译错误。常见的错误包括：

• 找不到编译器（gcc/make）：回到第一步，确保已离线安装gcc和make。
• 内核头文件路径不对或版本不匹配：这是最常见的问题。再次用uname -r和rpm -qa | grep kernel-devel双重确认。极端情况下，可能需要重启目标机，确保其运行的就是你安装了头文件的那个内核。

编译成功后，模块会自动加载。你可以用以下命令检查：

# 检查vmmon和vmnet模块是否已加载 lsmod | grep vm

应该能看到vmmon和vmnet等模块。

3.5 第五步：输入许可证并完成配置

在安装过程的最后，或者首次启动VMware Workstation时，会提示你输入许可证密钥。

# 如果你在安装时跳过了输入许可证，或者需要后续输入，可以使用命令行工具 sudo /usr/lib/vmware/bin/vmware-vmx --new-sn YOUR-LICENSE-KEY-HERE

将YOUR-LICENSE-KEY-HERE替换成你准备好的有效密钥。你也可以在首次启动图形界面时，在设置窗口中输入。

重要提示：对于完全无图形界面的服务器，你可能只需要VMware的命令行工具（如vmrun）来管理虚拟机。此时，许可证同样需要通过上述命令行方式输入。图形界面并非必需。

4. 安装后配置与验证

安装并输入许可证后，建议进行以下配置和验证，确保一切就绪。

4.1 配置网络（桥接/NAT）

VMware Workstation安装后会自动创建两个虚拟网络交换机：VMnet0（桥接模式）和VMnet8（NAT模式）。在离线环境，这些通常能自动工作。但如果你需要自定义网络（例如使用特定的物理网卡做桥接），可以编辑网络配置文件。

# 编辑VMware的网络配置文件 sudo vi /etc/vmware/networking

不过，对于大多数离线实验环境，默认的NAT网络已经足够虚拟机访问外部网络（宿主机）以及宿主机访问虚拟机。

4.2 将用户加入vmware用户组

为了让普通用户无需sudo就能启动VMware Workstation，需要将用户加入vmware组。

sudo usermod -aG vmware $USER

生效需要重新登录。登录后，可以使用groups命令查看当前用户是否已在vmware组中。

4.3 验证安装

1. 命令行验证：运行vmware --version，应该能输出VMware Workstation的版本信息。
2. 启动图形界面：在桌面环境终端输入vmware，应该能正常启动主程序。
3. 创建测试虚拟机：尝试创建一个最小化的Linux虚拟机（例如使用一个小的ISO镜像），测试虚拟机的安装、启动和网络功能是否正常。这是最终极的验证。

5. 常见问题排查与实战技巧

即使按照步骤操作，你也可能会遇到一些棘手的问题。下面是我在多次离线部署中总结的“排坑指南”。

5.1 内核模块编译失败：版本不匹配的终极解决

问题现象：运行sudo vmware-modconfig --console --install-all时，出现类似“The path “/usr/src/kernels/3.10.0-1160.el7.x86_64” is not a valid path to the 3.10.0-1160.95.1.el7.x86_64 kernel headers.”的错误。

根本原因：uname -r输出的内核版本（如3.10.0-1160.95.1.el7.x86_64）与已安装的kernel-devel包版本（如3.10.0-1160.el7.x86_64）在发行号上存在细微差异。这常见于系统更新了内核但未更新开发包，或者准备机和目标机的小版本号不同。

解决方案：

1. 首选方案：在目标机上，找到与uname -r输出完全一致版本的kernel-devel和kernel-headers的rpm包。这可能需要你在有网络的准备机上，通过访问发行版的官方仓库或镜像站，根据确切版本号搜索并下载。
2. 符号链接方案（应急）：如果实在找不到完全一致的包，可以尝试创建一个符号链接“欺骗”安装程序。此方法有风险，可能导致模块不稳定，仅用于测试环境。

   # 假设已安装的kernel-devel路径是 /usr/src/kernels/3.10.0-1160.el7.x86_64 # 而uname -r输出是 3.10.0-1160.95.1.el7.x86_64 sudo ln -s /usr/src/kernels/3.10.0-1160.el7.x86_64 /usr/src/kernels/3.10.0-1160.95.1.el7.x86_64

   然后重新运行vmware-modconfig。

5.2 安装过程中缺少依赖库（如libssl.so.10）

问题现象：运行Bundle安装包时，提示缺少某个共享库文件（.so文件）。

原因分析：虽然我们用rpm解决了包依赖，但某些库的特定版本可能未被覆盖。例如，旧版软件依赖libssl.so.10，但系统只有libssl.so.1.1。

解决方案：

1. 查找提供该库的rpm包：在准备机上，使用yum whatprovides */libssl.so.10命令，查找哪个rpm包提供了这个库文件。然后下载对应的旧版本rpm包。
2. 离线安装该特定版本包：将下载的旧版本rpm包拷贝到目标机，使用rpm -ivh或yum localinstall安装。注意，这可能会与现有新版本库冲突，需要评估影响。
3. 创建软链接（不推荐）：作为最后手段，可以手动创建从现有库到缺失库名的软链接。但这可能破坏其他依赖新版本库的软件，务必谨慎。

   # 示例：假设有libssl.so.1.1，但需要libssl.so.10 sudo ln -s /usr/lib64/libssl.so.1.1 /usr/lib64/libssl.so.10

5.3 VMware启动后虚拟机无法联网（NAT/桥接失败）

问题现象：虚拟机内部操作系统无法获取IP地址，或无法ping通宿主机和外网。

排查步骤：

1. 检查VMware网络服务：确保vmware-networks服务已启动。

   sudo systemctl status vmware-networks.service # 如果未运行，则启动它 sudo systemctl start vmware-networks.service sudo systemctl enable vmware-networks.service # 设置开机自启

2. 检查虚拟网络编辑器配置：在VMware主界面，点击“编辑”->“虚拟网络编辑器”。确保“NAT模式”和“桥接模式”对应的网络是“已连接”状态。在桥接模式下，确认桥接到的物理网卡是正确的（在有多个网卡的服务器上容易选错）。
3. 检查宿主机的iptables/nftables防火墙：离线环境的防火墙策略可能比较严格，可能会阻断虚拟机的网络流量。可以临时关闭防火墙测试，或添加针对vmnet接口的规则。

   # 临时关闭防火墙（测试用） sudo systemctl stop firewalld # 对于firewalld # 或 sudo systemctl stop iptables # 对于iptables服务

4. 检查虚拟机内部设置：确认虚拟机设置中的网络适配器类型（NAT/桥接）选择正确，并且是“已连接”状态。

5.4 图形界面启动缓慢或报GLX错误

问题现象：在服务器或最小化安装的桌面环境上启动VMware时，启动很慢，或者提示与OpenGL/GLX相关的错误。

原因与解决：VMware Workstation的图形界面需要3D加速支持。在无独立显卡或驱动不全的服务器上，可能会回落到软件渲染，导致速度慢。

• 安装基础图形驱动：确保已安装mesa-libGL、mesa-dri-drivers等包。这在我们的依赖收集阶段就应该完成。
• 使用软件渲染：如果性能不是首要问题，可以强制VMware使用软件渲染。编辑VMware的配置文件：

  sudo vi /etc/vmware/config

  在文件末尾添加一行：

  mks.gl.allowBlacklistedDrivers = "TRUE"

• 使用命令行管理：如果根本不需要图形界面，可以完全依赖vmrun命令行工具来创建、启动、停止和管理虚拟机，这对于自动化部署和服务器环境非常有用。

6. 进阶：打造可复用的离线安装仓库

如果你需要频繁在相同环境的离线机器上部署，每次都重复下载依赖包效率太低。一个专业的做法是构建一个本地的YUM/DNF仓库。

1. 在准备机上创建仓库：将下载的所有依赖包（包括kernel-devel等）放入一个目录，例如/data/vmware-repo。
2. 安装并配置createrepo工具：

   sudo yum install -y createrepo cd /data/vmware-repo createrepo .

   这个命令会生成仓库所需的元数据（repodata目录）。
3. 将整个/data/vmware-repo目录打包，拷贝到目标离线机。
4. 在目标机上配置本地YUM源：

   sudo vi /etc/yum.repos.d/local-vmware.repo

   添加以下内容：

   [local-vmware] name=Local VMware Dependencies Repository baseurl=file:///opt/vmware-repo # 根据你实际存放的路径修改 enabled=1 gpgcheck=0

5. 在目标机上安装：现在，你可以像在线安装一样，直接使用yum命令来安装依赖了，甚至可以将VMware的Bundle包也放入仓库，但通常Bundle包还是单独执行。

   sudo yum install kernel-devel-$(uname -r) gcc make perl ... # 列出所有需要的包名

   这种方式管理依赖更加清晰和自动化。

最后，我想分享的一点核心体会是：离线安装的成功，90%取决于准备阶段的依赖收集是否完整和版本是否精确。尤其是在内核版本这个点上，多花十分钟在准备机上核对清楚，能省去在目标机上数小时的折腾。养成在准备机上用yumdownloader --resolve或apt-get download完整拉取依赖的习惯，并仔细核对关键组件如gcc、kernel-devel的版本，你的离线部署之路会顺畅很多。当你在那台看似“孤立无援”的离线服务器上成功启动第一个虚拟机时，这种通过周密准备解决实际限制的成就感，是在线安装无法比拟的。