カーネル更新と再起動の前は VMware Workstation が動作していたのに、その後 vmnet または vmmon をコンパイルできないと表示される場合、まずカーネル切り替えを起点とする互換性インシデントとして扱います。すぐに VMware 同梱ソースを編集してはいけません。同じダイアログでも、製品とホストカーネルがサポート対象の組み合わせでない、実行中カーネルと一致するビルドツリーがない、コンパイラーまたはツールチェーンが合わない、モジュールは生成されたが Secure Boot が読み込みを拒否した、という少なくとも 4 種類の原因があります。
本ガイドは「カーネルを更新した直後」という事象から始め、証拠採取、一時復旧、サポートされる修復、ロールバックを扱います。詳細なバージョンサポート表、ディストリビューション別ヘッダー導入、MOK 手順は、サイト内の VMware カーネルヘッダーとサポート表ガイドを参照してください。
安全境界： まず全 VM を正常終了し、VM ファイルに独立した復元可能なバックアップがあることを確認します。長時間の root shell、
/usr/lib/vmware/modules/source内のアーカイブを展開して直接書き換える操作、出所不明のビルド済みモジュール、モジュールを読み込むためだけの Secure Boot 無効化は禁止です。リモートホストで再起動やカーネル切り替えを行う前に、帯域外コンソールを用意してください。古いカーネルは期限を決めた緊急ロールバックであり、セキュリティ更新を恒久的に固定する理由にはなりません。
Table of Contents
1. 変更前にインシデントの時系列を固定する
障害の前後で一意に変わったものを記録します。カーネルパッケージ、ホストのディストリビューション、VMware バージョン、Secure Boot/MOK 状態のどれでしょうか。次のコマンドは読み取り専用です。コマンドが存在しないことも証拠なので、推測したパッケージ名で結果を「補完」しないでください。
date -Is
uname -r
uname -m
cat /etc/os-release
vmware --version
last -x reboot | head -n 5
journalctl --list-boots続いてディストリビューション固有のパッケージ管理履歴から、新しいカーネルパッケージの正確な版と導入時刻を確認します。Debian/Ubuntu、Fedora/RHEL、openSUSE では履歴の確認方法が異なります。他のディストリビューションのインストールコマンドを転用せず、対象ディストリビューションの現行文書に従ってください。動作カーネルと障害カーネルの完全な uname -r を記録し、「6.x」だけで済ませないでください。
2. 元のログを保存し、共有前に機密情報を除く
Broadcom は、VMware がインストール時または初回起動時に vmmon と vmnet をローカルでビルドし、進捗が /tmp/vmware-root/vmware-PID.log に出る場合があると説明しています。まず候補ログを列挙し、削除や上書きはしません。
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'VMware ダイアログの最初のコンパイルエラーと前後の文脈も保存します。最終行は要約にすぎないことが多いためです。共有前にユーザー名、ホスト名、内部パス、内部リポジトリアドレス、インターフェースアドレス、トークンを削除します。.vmx、仮想ディスク、ライセンス資料、秘密鍵、VM の完全な一覧はアップロードしないでください。
3. 症状から推測せず、失敗段階で分類する
| 証拠の位置 | 想定される分類 | 次の行動 |
|---|---|---|
| 現在の VMware/ホスト/カーネルの組み合わせが Broadcom の表にない | サポート外の組み合わせ | ベンダーがサポートする VMware 版へ更新するか、ディストリビューションがまだ保守する既知の動作カーネルを一時的に起動する |
/lib/modules/<実行中カーネル>/build がない、または別カーネル用 | ヘッダー/ビルドツリー不一致 | 完全な uname -r と正確に一致する開発パッケージをディストリビューション公式リポジトリから導入する |
C コンパイル前に gcc、make、生成ツール不足が記録される | ツールチェーン不足 | VMware サポートとディストリビューション文書が指定する正確な前提だけを導入する |
| カーネル API、型、関数のコンパイルエラーがある | ソース/API 非互換 | VMware 更新またはサポート対象カーネルへの回退を優先し、別バージョン用パッチを適用しない |
| コンパイル成功後、カーネルログに署名、検証、lockdown エラーがある | Secure Boot/モジュール署名 | 現行のディストリビューション手順と Broadcom 手順で vmmon と vmnet の両方を署名・登録する |
| 両モジュールが読み込まれたが NAT、ブリッジ、またはネットワークだけ失敗する | 実行時ネットワーク問題 | 再コンパイルを繰り返さず、VMware サービス、仮想ネットワーク設定、ホストネットワークを診断する |
Broadcom の現行表は、特定の VMware 版、ホストリリース、一部のカーネル上限を示します。ディストリビューション名が一致しても、任意の HWE、OEM、自作、mainline カーネルがサポートされるとは限りません。
4. 実行中カーネル、ビルドツリー、ツールチェーンを確認する
外部モジュールは実行中カーネル向けにビルドする必要があります。Linux カーネル文書では、ビルドツリーに対応する設定とヘッダーが必要です。ディレクトリが存在しても別カーネルを指していれば不適切です。
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偽の build シンボリックリンクを作ったり、ランダムなミラーからヘッダーを取得したりしないでください。カーネルフレーバー、アーキテクチャ、設定、開発パッケージが相互に一致する必要があります。ビルドログが特定のコンパイラーを明示する場合は /proc/version のビルド情報と比較します。ただし小さな版差だけで自動的に失敗とせず、実際のエラーを根拠にします。ディストリビューション別パッケージ名はサイト内の詳細ガイドを参照してください。
5. サポートされ、可逆な復旧経路を先に選ぶ
リスクが低い順に進めます。
- 既知の動作カーネルを一時起動する。 ローカルまたは帯域外のブートメニューで、以前検証済みのカーネルを選びます。Ubuntu 公式の復旧文書では、GRUB の「Advanced options」から特定カーネルを選ぶ方法が示されています。新しいカーネルを削除せず、古いカーネルを恒久的な既定値にしません。新カーネルが脆弱性を修正している場合は、回退期間とホストの露出を最小にします。
- ベンダーがサポートする VMware 更新を確認して導入する。 Broadcom 公式ポータルまたは組織承認済みソースだけを使い、版、署名、リリースノートを検証し、対象ホストとカーネルがサポートされることを先に確認します。インストールメディア、設定バックアップ、回退版を保管します。
- ディストリビューションの完全一致する開発パッケージを補う。 証拠がビルドツリーまたはツール不足を示した場合だけ、公式リポジトリから導入します。単一モジュール修復のためにディストリビューション全体を盲目的に更新しません。
- 保守時間に公式モジュール再ビルドを一度だけ行う。 VM 停止、サポート組み合わせ、空き容量を確認した後に限り、権限付きで記録される次の 1 コマンドを実行します。
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"これは普遍的な成功保証ではありません。オプションは VMware のバージョン別インターフェースなので、実行前に導入済み版のヘルプと Broadcom 文書を確認します。セッション全体を root shell で包まないでください。最初のビルドが失敗したら最初のエラーを保存して停止します。再実行を繰り返しても、サポート外のカーネル API は修復できません。
6. 「コンパイル失敗」と「読み込み失敗」を分ける
ログでは .ko が生成済みなのに VMware が /dev/vmmon 不在を報告する場合、C コードを再び編集せず、Secure Boot と署名を調べます。
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'modinfo がモジュールを見つけられない場合、通常はまだビルド/導入の問題です。モジュールパスはあるが signer が空で、カーネルが署名を拒否している場合に署名経路を疑います。Broadcom の公式手順は vmmon と vmnet の両方を対象とし、Ubuntu も Secure Boot 下のローカルビルドモジュールには信頼済み署名と MOK 登録が必要だと説明しています。秘密鍵はホスト管理者だけがアクセスできるよう制限し、記事、チケット、リポジトリ、チャットに入れてはいけません。再ビルドごとに再署名が必要になる場合があります。Secure Boot の無効化を修復の代わりにしないでください。
7. vmnet 読み込み後のネットワーク障害は別の故障系統
ネットワーク変更を決める前に、モジュール状態と VMware のユニット名を証明します。
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'サービス名とネットワーク構成は製品、ディストリビューション、導入方法で変わります。ログに vmnet があるだけで /etc/vmware/networking を削除したり、全仮想ネットワークを作り直したり、ファイアウォールを空にしたり、本番ブリッジを変えたりしないでください。VMware ネットワーク設定をバックアップし、期待する NAT/host-only/bridge 状態を記録したうえで、現行版の Virtual Network Editor または公式管理画面から、回退点のある変更を一つだけ行います。ブリッジはホストの NetworkManager、無線制限、VPN、名前空間、ファイアウォールにも影響されます。
8. コミュニティ製モジュールパッチは管理された例外に限る
コミュニティパッチは「最新カーネル向けワンコマンド修復」ではありません。ベンダーがサポートする製品/カーネル組み合わせがなく、所有者がサポート外運用を明示的に受容し、隔離ホストで検証できる場合に限って検討します。審査条件は次のとおりです。
- パッチは VMware 完全版、カーネル完全版、アーキテクチャに厳密に対応させます。ソース差分だけを審査し、出所不明のビルド済み
.koは拒否します。 - コミットまたはリリースタグを固定し、来歴、ライセンス、ハッシュ、審査者、パッチ差分を記録します。まず使い捨てテストホストでビルドし、セキュリティ審査を行います。
- インストール済み
vmnet.tar/vmmon.tarを直接編集せず、別版の行番号置換を盲目的にコピーせず、ダウンロード直後に root shell へ入るスクリプトを実行しません。 - 元パッケージと起動可能な既知の動作カーネルを保管します。製品またはカーネルの更新ごとにパッチを再審査し、黙って再利用しません。
- 生成モジュールにも Secure Boot の署名ポリシーが適用されます。ソース、ビルドチェーン、署名鍵の信頼境界を説明できなければ停止し、Broadcom、ディストリビューションベンダー、組織管理者へエスカレーションします。
本番ホスト、規制対象環境、機密 VM を持つ端末では、コミュニティブランチを長期保守策にせず、通常は明示的にサポートされる組み合わせへ移行すべきです。
9. 検証、ロールバック、停止条件
対象カーネルを起動した後、GUI が開くかだけで判断せず、同じ証拠を再採取して比較します。
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'最初に機密データを持たない隔離テスト VM を起動し、終了、再起動、実際に使う NAT、host-only、bridge モードを検証します。本番 VM を最初のテストにしないでください。検証失敗時は、記録済みの動作カーネルまたは承認済み VMware 版へ戻し、新旧ログを保管します。
次のいずれかなら停止します。サポート表に組み合わせがない、最初のエラーが未知のカーネル API、Secure Boot 無効化・盲目的なソース置換・未署名バイナリが必要、帯域外コンソールなしのリモート接続だけ、VM に検証済みバックアップがない、組織管理ホスト、または回退カーネルのセキュリティ保守が終了済み。公式サポートまたは管理者へ、VMware 版、完全なカーネル版、ディストリビューション、アーキテクチャ、最初の機密除去済みエラー、Secure Boot 状態、試した単一変更を渡してください。
公式資料
- Broadcom：現行 VMware Workstation ホスト OS サポート表
- Broadcom：カーネルモジュールのコンパイル失敗とサポート組み合わせ
- Broadcom：Linux カーネル更新後の Workstation モジュール再ビルド
- Broadcom：Secure Boot 下での vmmon と vmnet の署名
- Linux カーネル文書：外部モジュールのビルド
- Linux カーネル文書：モジュール署名機構
- Ubuntu：UEFI Secure Boot とサードパーティーモジュール
- Canonical：GRUB 復旧モードで特定カーネルを選ぶ
歴史的原文アーカイブ（来歴確認専用・実行禁止）
以下は 2014 年当時の問題背景と来歴を保つため、source_export の可視本文を完全に収録したものです。root 操作、VMware 内部アーカイブの直接書き換え、古いカーネル API 置換、削除コマンドは現行手順ではなく、本ガイドは推奨しません。 削除、改稿、空白の正規化、プライバシー/安全上の編集は一切行っていません。外部アドレスは不活性なプレーンテキスト囲い内にあり、本稿の推奨リンクではありません。
最近将ubuntu升级到了14.04,出现了vmware无法启动的情况。具体表现为：每次启动的时候都会弹出一个VMWare Kernel Module Updater的对话框，要求根据当前内核版本重新编译一些内核模块，但是其中网络模块vmnet总是编译失败。
查找相关资料发现原因在于升级到ubuntu 14.04之后现在的Linux内核版本是3.13，这个内核版本修改了一些底层函数，而VMWare的相关源码包还没有来得及修改相关代码。由于是内核版本的问题，所以同样的问题也大量出现在Fedora等系统上。
因此同样的问题可以继续存在于3.14, 3.15等后续版本中。
解决方法为修改vmnet模块的源码包中的两处代码。
1,获取root权限，进入相关目录：
su
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
转载请注明出处