先说个真实经历。去年我在一台 Ubuntu 22.04 的机器上装 VMware Workstation 17 Pro，装完建虚拟机，想用仅主机模式搭个隔离测试环境，打开虚拟网络编辑器一看，里面干干净净只剩一个 VMnet0。ip link 敲下去，vmnet1、vmnet8 连影子都没有。当时第一反应是重装，结果重装完还是一样，后来才发现是 VMware 在 Linux 下的网络组件没有正确加载。这个问题在 Windows 下并不多见，但 Linux 下遇到的人真不少，网上一堆复制粘贴的答案，不是让你去 Windows 服务里找 VMware NAT Service，就是让你换发行版，完全不搭边。我折腾了两天，最终在不重装系统的前提下把两个虚拟网卡都找了回来，而且后面换过几台机器、换过 Fedora 和 Debian，这套方法都管用。
这篇东西不是理论分析，是我实打实跑通的步骤。我会先讲清楚 VMnet1 和 VMnet8 在 Linux 下到底是怎么出现的，再给你一套按顺序执行的操作流程，最后把那些容易复发、容易误判的坑单列出来。只要你能打开终端，照着敲，基本都能解决。
1. 先搞清楚VMnet1和VMnet8到底是怎么来的
1.1 VMware虚拟网络在Linux下不是“装出来”的，是“加载出来”的
很多人一看到“没有VMnet1和VMnet8”，第一反应是软件没装好，或者安装包有问题。实际上，VMware Workstation 在 Linux 上的安装过程包含两部分：一部分是普通的用户态程序，比如 vmware-workstation-server、vmware-netcfg 这些；另一部分是内核模块，其中包括 vmmon 和 vmnet。vmmon 负责虚拟机运行时的CPU和内存资源管理，vmnet 则专门负责虚拟网络交换。
VMnet1 和 VMnet8 之所以叫“虚拟网卡”，是因为它们在宿主机上会以网络接口的形式出现。Linux 下打开终端执行 ip link，正常情况下能看到 vmnet1 和 vmnet8 这两个设备。它们的本质是内核模块 vmnet 创建出来的虚拟交换机设备，而不是像 Windows 那样由“设备管理器”里一个独立驱动装出来的网卡。所以整个链条是这样的：vmnet 模块被加载 → udev 或服务脚本创建设备节点 /dev/vmnet1、/dev/vmnet8 → systemd 服务读取 /etc/vmware/networking 配置文件 → 内核创建 vmnet1、vmnet8 网络接口。
链条上任何一环断裂，结果都是“没有虚拟网卡”。最常见的断裂点有三个：内核模块没编译成功、systemd 服务没启动、配置文件损坏或丢失。下面每一步都是围绕这三个点做修复，所以你理解了这条链路，后面操作就不会是瞎试。
1.2 VMnet0、VMnet1、VMnet8 各自干什么
简单过一遍三个默认虚拟网络的作用，方便你判断自己到底少了什么、影响有多大。
VMnet0 是桥接模式，VMware 在启动时会把它和一个物理网卡绑定。虚拟机通过它可以直接和局域网里的设备通信，就像另一台真实主机。VMnet1 是仅主机模式，虚拟机和宿主机之间组成一个私有网络，默认不提供对外网访问，适合做隔离测试。VMnet8 是 NAT 模式，虚拟机通过宿主机转发访问外部网络，外部网络看不到虚拟机本身，但虚拟机可以上网。
在 Linux 下，如果 vmnet1 不存在，你新建虚拟机时网卡模式里即使选了“仅主机”，虚拟机内部也可能拿不到IP，或者干脆没有对应网络。如果 vmnet8 不存在，NAT 模式的虚拟机一样上不了网。很多人的表现不是“完全没网”，而是“虚拟机桥接能用，NAT用不了”，实际上就是VMnet8缺失。搞清楚这一点，你在排查时就能少走很多弯路。
2. 动手前的三分钟排查：先定位是模块、服务还是配置文件的问题
2.1 四个命令快速定位
不要一上来就重装，先花三分钟把现象确认清楚。打开终端，依次执行下面几条命令，把输出记下来。
第一条，看网卡接口是否存在：
ip link show重点看有没有 vmnet1、vmnet8。如果你的系统里 ifconfig 还能用，也可以敲 ifconfig -a。注意用 -a，因为有些网卡状态是 DOWN 的时候普通 ifconfig 不带参数是看不到的。
第二条，看内核模块有没有加载：
lsmod | grep vmnet正常情况下会输出 vmnet 以及它依赖的 vmmon。如果什么都没有，说明 vmnet 模块压根没加载。
第三条，看VMware相关服务状态：
systemctl list-units | grep vmware systemctl status vmware-networks不同发行版的服务名略有差异，可能是 vmware.service、vmware-networks.service、vmware-networks-configuration.service，先用第一条命令把所有带 vmware 的列出来，再逐个看状态。
第四条，看虚拟网络设备节点：
ls -l /dev/vmnet*如果这里连 /dev/vmnet 相关设备都没有，问题大概率出在模块加载或设备节点创建上。
2.2 对照表格判断你属于哪种情况
把上面的输出组合起来，基本能定位到方向。我整理了一张速查表：
| 现象 | 可能原因 | 优先尝试方向 |
|---|---|---|
| lsmod 里没有 vmnet | 内核模块未加载或编译失败 | 重新编译 vmnet 模块 |
| 有 vmnet 模块但 /dev/vmnet* 不存在 | 设备节点未创建、udev 异常 | 重启 vmware-networks 服务 |
| /dev/vmnet* 存在但 ip link 没有接口 | 配置文件丢失或NetworkManager干扰 | 重建 /etc/vmware/networking |
| 只有 VMnet0，没有 VMnet1/VMnet8 | /etc/vmware/networking 不完整 | 删除配置后重新生成 |
| 服务启动报错、状态一直失败 | 配置文件损坏或端口被占用 | 查看日志 journalctl，重置配置 |
这张表不绝对，但足够帮你确定第一步该干什么。我自己遇到的情况就是表里第三行加第四行的组合：模块加载正常，但 /etc/vmware/networking 损坏，导致只有默认的VMnet0，另外两个网络没有创建。
3. 亲测修复流程：按顺序执行，每一步都有结果验证
3.1 第一步：重启VMware服务，看网卡是否回来
做事别跳步，先从最温和的操作开始。先试着把VMware的整套服务重启一遍：
sudo systemctl restart vmware sudo systemctl restart vmware-networks如果你的发行版没有 vmware.service，用第二步systemctl list-units | grep vmware找出来的实际服务名替代。重启之后立刻看状态：
systemctl status vmware-networks sudo vmware-networks --statusvmware-networks 是VMware自带的网络管理脚本，--status 会打印当前虚拟网络状态。如果这里输出正常，再执行 ip link show 确认 vmnet1、vmnet8 是否出现。
这一步能解决一部分问题，特别是安装完成后系统还没完全初始化服务、或者服务因临时异常退出的情况。如果网卡回来了，那恭喜你，问题基本结束。但如果你像我一样，服务显示 active 但接口就是不出来，继续往下走。
3.2 第二步：删除损坏的 /etc/vmware/networking 并重建默认配置
这一步是整篇文章的核心，也是我亲测最管用的一招。前面说过，VMware 在 Linux 下创建虚拟网络时，会读取 /etc/vmware/networking 这个文本文件。这个文件里记录着每个 VMnet 的类型、子网、DHCP 开关等信息。如果它被升级过程、异常断电、或者手动误改搞坏了，VMware 宁可只保留最基本的 VMnet0，也不愿意自己乱猜，于是 VMnet1 和 VMnet8 就消失了。
解决思路很粗暴：先把原文件备份，再删掉，然后触发 VMware 重新生成默认配置。执行：
sudo vmware-networks --stop sudo cp /etc/vmware/networking /etc/vmware/networking.bak sudo rm /etc/vmware/networking sudo vmware-networks --start注意 --stop 和 --start 之间最好隔几秒，给模块一点卸载时间。重新 start 之后，VMware 会按内置默认模板创建出 VMnet0、VMnet1、VMnet8 三个网络。此时再看 ip link，应该能看到了。
这里要特别提醒：不要在没备份的情况下直接删除配置文件。万一你的 VMnet8 子网是手动改过的特殊网段，重建后会回到默认的 192.168.x.x 段，你的虚拟机如果绑定了固定IP，后面还得改回来。有备份在手，至少能对照原配置找回网段信息。
3.3 第三步：重新编译vmnet内核模块（内核升级后必看）
如果重启服务、重建配置都没用，而且执行 lsmod | grep vmnet 时一片空白，多半是内核模块本身有问题。最常见的场景是：你安装VMware时系统内核是 A 版本，后来执行了系统更新，内核升级到了 B 版本，VMware 的模块还停留在 A 版本，自然加载不了。
这种情况需要重新编译内核模块。执行：
sudo vmware-modconfig --console --install-all这个命令会重新编译和安装 vmmon、vmnet 等所有内核模块。编译过程会有输出，日志里能看到它正在调用 gcc、make 之类的工具。如果你的系统缺少编译环境，会直接报错，提示找不到 kernel headers 或 GCC。所以在这之前，先确保依赖装好。
Ubuntu/Debian 系执行：
sudo apt install build-essential linux-headers-$(uname -r)Fedora/RHEL 系执行：
sudo dnf install kernel-devel kernel-headers gcc make装完依赖后重新执行 vmware-modconfig，看到模块编译成功的日志后，再重启VMware服务。实测下来，很多人在这一步解决了问题：网卡回来了，虚拟机网络也恢复正常。
3.4 第四步：用 vmware-netcfg 图形工具手动添加VMnet1/VMnet8
前面三步都属于“让VMware自己恢复”。如果它们都失败，还有一条路：手动添加。VMware 在 Linux 下有一个图形工具叫 vmware-netcfg，作用和Windows版虚拟网络编辑器一样。执行：
sudo vmware-netcfg界面打开后你会看到当前的虚拟网络列表。如果只有 VMnet0，点界面上的 Add Network 按钮，根据提示选择 Host-only，VMware 会创建 VMnet1；再添加一个 NAT 网络，创建 VMnet8。子网地址你可以手动指定，比如 VMnet1 用 192.168.200.0/24，VMnet8 用 192.168.111.0/24，也可以用默认值。
保存后回到终端，执行 ip link show，正常情况下就能看到 vmnet1 和 vmnet8 了。有一点要注意：如果 vmnet 模块本身没加载，这个工具的添加按钮可能是置灰的，或者保存时报错。所以手动添加之前，先确认 lsmod | grep vmnet 有输出，否则先回到 3.3 解决模块问题。
4. 内核模块没加载时最容易被忽略的几个细节
4.1 modprobe 报错到底在说什么
有读者反馈，执行 sudo modprobe vmnet 时，系统直接报错。比如常见的错误信息是 modprobe: ERROR: could not insert 'vmnet': Exec format error，或者 Unknown symbol in module。这基本可以断定是模块版本和当前内核不匹配。原因无非两种：内核更新后没有重新编译VMware模块，或者VMware版本太老、支持不了新内核。
遇到这种报错，不要去改模块文件权限，也不要去下载所谓“通用”模块。正确做法就是 3.3 里的 vmware-modconfig --console --install-all，让VMware重新生成适配当前内核的模块。如果你用的VMware版本确实太老，比如15.x在6.5内核上，官方也可能不提供适配，那就只能升级VMware版本。
4.2 编译vmnet需要哪些系统依赖
很多人在 Linux 上装 VMware，全程 Next 一路到底，直到功能缺失才发现少了东西。vmnet 模块编译成功不仅需要内核头文件，还依赖编译器、make 工具和正确的内核开发包。以 Ubuntu 为例，最容易缺的是 linux-headers-$(uname -r)。注意这个包名必须和当前内核版本完全一致，更新内核后头文件版本也要跟着变。
安装依赖之后再执行 vmware-modconfig，如果依然报错，看一下 /tmp/vmware-root/ 下的日志，通常会有 vmware-vmmodconfig.log 文件，里面记录着编译失败的真正原因，可能是路径不对、缺少符号、权限不足，比网上乱猜要靠谱得多。
4.3 怎么验证VMware服务是否真的“活着”
systemctl status 显示 active (running)，不代表虚拟网络就正常。更准确的验证方式是直接看 VMware 的网络管理脚本状态：
sudo vmware-networks --status这个命令会尝试连接 vmnet 模块，并打印每个虚拟网络的状态。如果它输出类似 Network config on this machine is not working 这样的提示，说明模块和服务之间有沟通问题。这时候再看 systemctl status vmware-networks 的日志，通常能拿到更具体的错误码。记住一个原则：优先信 vmware-networks --status 的结果，而不是 systemctl 的绿色字体。
5. 常见问题与避坑实录
5.1 服务正常但 ip link 里就是看不到 vmnet 接口
这种情况我遇到过两次。一次是 NetworkManager 接管了虚拟网卡，把它标记成未管理或者干脆隐藏；另一次是 vmnet 接口创建了，但一直处于 DOWN 状态，而 ip link 输出中接口名被省略了。
先别怀疑前面的操作白做，执行一下：
sudo ip link set vmnet1 up sudo ip link set vmnet8 up如果接口仍然不出现，检查 NetworkManager 配置。在 /etc/NetworkManager/NetworkManager.conf 的 [keyfile] 段中加入一行：
unmanaged-devices=interface-name:vmnet1;interface-name:vmnet8然后重启 NetworkManager，让虚拟网卡彻底脱离它的管束。注意不同发行版的 NetworkManager 配置写法可能不同，但思路一致：不要把 vmnet 接口交给网络管理工具自动处理。
5.2 虚拟机网络适配器模式里只有桥接选项
打开虚拟机设置，网络连接那一栏只有 Bridge，没有 Host-only 和 NAT，说明 VMnet1 和 VMnet8 没有注册到VMware的网络模块里。这种情况和第一个问题很像，但也可能是 /etc/vmware/networking 里根本没有这两个网络的定义。处理方式回到 3.2，删除配置重新生成，或者用 vmware-netcfg 手动添加。
还有一个容易踩的坑：修改完配置回到虚拟机设置，发现下拉框依然没有新选项。此时需要重启一下VMware Workstation主程序，甚至注销当前用户重新登录，让主程序重新读取虚拟网络配置。
5.3 重装VMware之后还是没有网卡
这个问题最让人崩溃。我的建议是，重装时不要只盯着安装进度条，要把终端输出看完。安装 bundle 版本时，最后一步会编译内核模块，如果编译失败，安装器通常会有明显的 WARNING，比如 Services did not start properly。但很多人直接忽略了。
如果你已经重装完才发现没网卡，不用再重装第三次。直接执行 vmware-modconfig --console --install-all，把模块补上即可。同时检查 /etc/vmware/networking 是否还在，如果安装过程把它清理了，执行 3.2 重建。
5.4 已经解决的问题又在重启后复发
还有一类情况：当下修复好了，但电脑一重启又打回原形。原因通常是VMware相关服务没有设置为开机自启，或者服务启动顺序和模块创建顺序冲突。用下面命令把所有VMware服务设为开机启动：
sudo systemctl enable vmware sudo systemctl enable vmware-networks sudo systemctl enable vmware-usbarbitrator如果系统里服务名不是这些，用 systemctl list-unit-files | grep vmware 查出来，逐个 enable。另外，如果你的重启非常频繁，而且每次都要重新 modprobe vmnet，检查一下有没有装类似 open-vm-tools 的组件和VMware自带的vmnet模块冲突。这种冲突在某些发行版上表现为服务启动时模块加载失败，把 open-vm-tools-desktop 卸载掉试试。
最后分享一个我自己的习惯。在 Linux 上用 VMware，每次装完系统后的第一件事不是急着建虚拟机，而是先把 build-essential 和 linux-headers 装上。很多人觉得这是多余的，直到内核更新后模块编译失败才开始后悔。VMware 在 Linux 下最不稳定的一环，其实就是它和内核之间的那层模块，只要摸清这个逻辑，再遇到虚拟网卡消失就不会慌。先备份、再重建配置、再查模块、最后手动添加，按这个顺序走下来，绝大多数问题都能解决。希望这篇内容能帮你少走点弯路。
