VMware vmnet Fails After a Linux Kernel Update: Evidence, Recovery, and Safe Rollback

If VMware Workstation worked before a kernel update and reboot but now says that vmnet or vmmon cannot be compiled, treat it first as a compatibility incident triggered by the kernel switch—not as a reason to edit VMware's bundled source immediately. The same dialog can represent at least four different failures: the product and host kernel are outside a supported combination, the running kernel lacks its matching build tree, the compiler or toolchain is mismatched, or the modules were built but Secure Boot refused to load them.

This guide starts at the “kernel was just updated” event and covers evidence capture, temporary recovery, supported repair, and rollback. For a fuller version support matrix, distribution-specific header installation, and the MOK workflow, see the site's VMware kernel headers and support-matrix guide.

Safety boundary: Shut down every VM cleanly first and confirm that the VM files have an independent, restorable backup. Do not open a long-lived root shell, unpack and rewrite archives under /usr/lib/vmware/modules/source, run untrusted prebuilt modules, or disable Secure Boot just to load a module. A remote host needs out-of-band console access before any reboot or kernel switch. An older kernel is a time-bounded emergency rollback, not a reason to freeze security updates indefinitely.

Table of Contents

1. Freeze the incident timeline before changing anything

Record what uniquely changed around the failure: the kernel package, host distribution, VMware version, or Secure Boot/MOK state. The commands below are read-only. A command that is unavailable is itself evidence; do not “complete” the picture with guessed package names.

date -Is
uname -r
uname -m
cat /etc/os-release
vmware --version
last -x reboot | head -n 5
journalctl --list-boots

Then inspect the distribution's own package-manager history to establish the exact new kernel package and installation time. Debian/Ubuntu, Fedora/RHEL, and openSUSE use different history interfaces; follow the current documentation for that distribution instead of copying another distribution's install commands. Record the complete uname -r for both the working and failing kernels, not merely “6.x.”

2. Preserve the original logs and sanitize before sharing

Broadcom explains that VMware builds vmmon and vmnet locally during installation or first launch, and progress may appear in /tmp/vmware-root/vmware-PID.log. List candidate logs first; do not delete or overwrite them:

find /tmp/vmware-root -maxdepth 1 -type f -name 'vmware-*.log' -printf '%T@ %pn' 2>/dev/null | sort -nr | head
journalctl -k -b --no-pager | grep -Ei 'vmmon|vmnet|module|verification|signature|lockdown|required key'

Also preserve the first compilation error in the VMware dialog with its surrounding context; the final line is often only a summary. Before sharing, remove usernames, hostnames, internal paths, private repository addresses, interface addresses, and tokens. Do not upload .vmx files, disks, license material, private keys, or a complete VM inventory.

3. Classify the failing stage instead of guessing from the symptom

Evidence location	Likely class	Next move
Current VMware/host/kernel combination is absent from Broadcom's table	Unsupported combination	Update to a vendor-supported VMware version, or briefly boot a known-good kernel that the distribution still maintains
`/lib/modules/<running-kernel>/build` is missing or belongs to another kernel	Header/build-tree mismatch	Install the development package that exactly matches the full `uname -r` from the distribution's official repository
Log reports missing `gcc`, `make`, or generation tools before C compilation	Missing toolchain	Install only the exact prerequisites named by VMware support and the distribution documentation
Log contains kernel API, type, or function compilation errors	Source/API incompatibility	Prefer a VMware update or a supported-kernel rollback; do not apply a patch for another version
Compilation succeeds, but the kernel log reports signing, verification, or lockdown errors	Secure Boot/module signing	Sign and enroll both `vmmon` and `vmnet` using the current distribution and Broadcom procedure
Both modules are loaded, but NAT, bridging, or only networking fails	Runtime network problem	Diagnose VMware services, virtual-network configuration, and host networking instead of recompiling again

Broadcom's current matrix identifies specific VMware versions, host releases, and some kernel ceilings. A matching distribution name does not imply support for every HWE, OEM, self-built, or mainline kernel.

4. Verify the running kernel, build tree, and toolchain

An external module must be built for the running kernel. The Linux kernel documentation says that its build tree must contain the corresponding configuration and headers; a directory that exists but points at another kernel is still wrong.

KernelRelease="$(uname -r)"
readlink -f "/lib/modules/$KernelRelease/build"
test -r "/lib/modules/$KernelRelease/build/Makefile" && echo 'build tree present' || echo 'build tree missing'
cat /proc/version
gcc --version
make --version

Do not fabricate a build symlink or download headers from a random mirror. Kernel flavor, architecture, configuration, and development package must match. If the build log explicitly requires a particular compiler, compare it with the build information in /proc/version; a small version difference is not automatically a failure, so use the actual error as evidence. See the deeper site guide for distribution-specific package names.

5. Choose a supported, reversible recovery path first

Work upward in risk:

Temporarily boot the known-good kernel. Choose the previously verified kernel in the local or out-of-band boot menu; Ubuntu's official recovery documentation shows how GRUB “Advanced options” exposes a specific kernel. Do not delete the new kernel or make the old one the permanent default. If the new kernel fixes a security vulnerability, minimize both the rollback window and host exposure.
Check and install a vendor-supported VMware update. Use only the official Broadcom portal or an organization-approved source; verify version, signature, and release notes, then confirm that the release supports the target host and kernel. Retain installation media, configuration backup, and a rollback version.
Supply the exactly matching distribution development packages. Do this only when evidence shows a missing build tree or tool, and use the distribution's official repository. Do not blindly upgrade an entire distribution as a module fix.
Run the official module rebuild once in a maintenance window. Only after VMs are off, the support combination is valid, and space is sufficient should this single privileged, logged command be run:

EvidenceDir="$PWD/vmware-kernel-evidence"
umask 077
mkdir -p "$EvidenceDir"
LogPath="$EvidenceDir/vmware-modconfig-$(date +%Y%m%d-%H%M%S).log"
test ! -e "$LogPath" || exit 1
set -o pipefail
sudo vmware-modconfig --console --install-all 2>&1 | tee "$LogPath"
BuildStatus="${PIPESTATUS[0]}"
echo "vmware-modconfig exit status: $BuildStatus"

This is not a universal success guarantee: the options are a VMware version interface, so check the installed version's help and Broadcom documentation first. Do not wrap the session in a root shell. If the first build fails, preserve its first error and stop; repeated rebuilds cannot repair an unsupported kernel API.

6. Separate “failed to compile” from “failed to load”

If the log shows that .ko files were produced but VMware still reports a missing /dev/vmmon, inspect Secure Boot and signatures instead of editing C code again:

command -v mokutil >/dev/null && mokutil --sb-state
modinfo -F filename vmmon
modinfo -F signer vmmon
modinfo -F filename vmnet
modinfo -F signer vmnet
journalctl -k -b --no-pager | grep -Ei 'vmmon|vmnet|verification|signature|lockdown|required key'

If modinfo cannot find a module, the problem is normally still build/install. A module path with an empty signer plus a kernel rejection points instead to signing. Broadcom's official instructions cover both vmmon and vmnet; Ubuntu likewise documents that locally built modules need a trusted signature and MOK enrollment under Secure Boot. The host administrator must keep the private key access-restricted; it must never enter an article, ticket, repository, or chat. A module may need signing again after every rebuild. Do not substitute disabling Secure Boot for a repair.

7. A loaded `vmnet` with broken networking is a different failure chain

Prove the module state and VMware unit names before deciding on a network change:

lsmod | grep -E '^(vmmon|vmnet) '
ip -brief link
systemctl list-unit-files --no-pager | grep -i vmware
journalctl -k -b --no-pager | grep -Ei 'vmnet|bridge|nat|filter'

Service names and network layouts vary by product, distribution, and installation method. Do not delete /etc/vmware/networking, recreate every virtual network, flush the firewall, or change a production bridge merely because a log mentions vmnet. Back up VMware's network configuration, record expected NAT/host-only/bridge state, and make one rollback-ready change through the current Virtual Network Editor or official administration interface. Bridging can also be affected by the host's NetworkManager, wireless restrictions, VPN, namespaces, or firewall.

8. Community module patches are controlled exceptions only

A community patch is not a one-command cure for “the newest kernel.” Consider one only when there is no vendor-supported product/kernel combination, the owner explicitly accepts unsupported operation, and validation is possible on an isolated host. The review gates are:

The patch must bind to the complete VMware version, complete kernel version, and architecture. Review source diffs only; reject untrusted prebuilt .ko files.
Pin a commit or release tag and record provenance, license, hash, reviewer, and patch diff. Compile first on a disposable test host and perform a security review.
Do not directly edit installed vmnet.tar/vmmon.tar, blindly copy line-number substitutions from another version, or run a downloaded script that immediately enters a root shell.
Keep the original package and a bootable known-good kernel. Review the patch again after every product or kernel update; never reuse it silently.
The resulting modules still have to satisfy Secure Boot signing policy. If source, build-chain, or signing-key trust boundaries cannot be explained, stop and escalate to Broadcom, the distribution vendor, or the organization administrator.

Production hosts, regulated environments, and devices holding sensitive VMs should normally move to an explicitly supported combination instead of treating a community branch as a long-term maintenance strategy.

9. Validate, roll back, and know when to stop

After booting the target kernel, collect the same evidence again and compare it rather than checking only whether the GUI opens:

uname -r
modinfo -F filename vmmon
modinfo -F vermagic vmmon
modinfo -F signer vmmon
modinfo -F filename vmnet
modinfo -F vermagic vmnet
modinfo -F signer vmnet
lsmod | grep -E '^(vmmon|vmnet) '
journalctl -k -b --no-pager | grep -Ei 'vmmon|vmnet|verification|signature|lockdown|required key'

Start an isolated test VM with no sensitive data first. Verify shutdown, a second start, and the NAT, host-only, or bridge mode actually used; do not make a production VM the first test. If validation fails, return to the recorded working kernel or approved VMware version and preserve both the before and after logs.

Stop on any of these conditions: the support matrix omits the combination; the first error is an unknown kernel API; success would require disabling Secure Boot, blind source substitutions, or unsigned binaries; access is remote with no out-of-band console; the VMs lack verified backups; the host is organization-managed; or the rollback kernel no longer receives security maintenance. Give official support or the administrator the VMware version, complete kernel version, distribution, architecture, first sanitized error, Secure Boot state, and the single change already attempted.

Official sources

Historical source archive (provenance only; do not execute)

The complete visible source_export body follows solely to preserve the 2014 problem context and provenance. Its root operations, direct rewriting of VMware internal archives, obsolete kernel-API substitutions, and deletion command are not current instructions and are not endorsed by this guide. Nothing was deleted, rewritten, whitespace-normalized, or redacted for privacy/safety. External addresses remain inside an inert plain-text fence and are not recommended links.


最近将ubuntu升级到了14.04,出现了vmware无法启动的情况。具体表现为：每次启动的时候都会弹出一个VMWare Kernel Module Updater的对话框，要求根据当前内核版本重新编译一些内核模块，但是其中网络模块vmnet总是编译失败。

查找相关资料发现原因在于升级到ubuntu 14.04之后现在的Linux内核版本是3.13，这个内核版本修改了一些底层函数，而VMWare的相关源码包还没有来得及修改相关代码。由于是内核版本的问题，所以同样的问题也大量出现在Fedora等系统上。

因此同样的问题可以继续存在于3.14, 3.15等后续版本中。

解决方法为修改vmnet模块的源码包中的两处代码。

1,获取root权限，进入相关目录：

cd /usr/lib/vmware/modules/source


2,解压vmnet源码包（得到vmnet-only文件夹）：

tar -xf vmnet.tar


3,备份原来的文件：

mv vmnet.tar vmnet.tar.bak


4,修改源文件filter.c：

4.1,修改206行的：VNetFilterHookFn(const unsigned int hooknum // IN:

为：VNetFilterHookFn(const struct nf_hook_ops *ops, // IN:

4.2,修改255行的： transmit = (hooknum == VMW_NF_INET_POST_ROUTING);

为： transmit = (ops->hooknum == VMW_NF_INET_POST_ROUTING);

5,打包修改过的文件，删除无用的文件

tar -uf vmnet.tar vmnet-only

rm -rf vmnet-only


6,重新编译内核模块，启动vmware

可以直接点击vmware workstation的图标，启动自动检测和编译过程；也可以通过命令：

vmware-modconfig --console --install-all


感谢：Bearox和Garrett Skjelstad

http://blog.csdn.net/bearox/article/details/21294609

http://ping8888.com/2013/12/13/vmware-modules-kernel-3-13/

原载于http://blog.csdn.net/yanxiangtianji

转载请注明出处