LinuxでVirtualBoxがフリーズする「unchecked MSR」エラーの原因と対処法

Linux、VirtualBoxのフリーズ、unchecked MSRエラー

更新日：2025年11月28日

今回は、ちょっと変わった現象についてお話しします。Linux（UbuntuやFedoraなど）を使っていて、VirtualBoxなどの仮想化ソフトウェアで仮想マシンを起動すると、時々動作が固まり、最悪の場合ホストOS全体が応答しなくなる——そんな症状です。筆者はVirtualBox 7.X以降、Kubuntu 22.04以降の環境でこの問題に気づきました。

長い試行錯誤の末、ようやく根本的な原因をつかめたと思います。これはカーネルのバグ、Spectre系脆弱性への対策（mitigation）、ホストとハイパーバイザーの衝突などが組み合わさって生じる、いわば無意味なバグの一種です。つまり、一般ユーザーがLinuxデスクトップを真剣に使う上でのまた一つの障害ですが、幸いにも私のような変わり者が、なんとか動くようにしようと挑戦しています。それでは、順を追って見ていきましょう。

問題の詳細

症状は非常にシンプルです。任意の仮想化ソフトウェアで仮想マシンを起動すると、ある時点で仮想マシンが応答しなくなります。プログラムのアイコンをクリックしただけで発生することもあります。さらに、ホスト側のデスクトップも正常に動作しなくなり、マウスクリックに反応しなかったり、特定のアプリだけが固まったりします。場合によっては自然に回復することもありますが、そうでない場合は強制再起動が必要です。実に厄介な問題です。

筆者はこの問題に数ヶ月間悩まされてきました。もちろん、これもカーネル由来の問題です。以前、Titanラップトップの不調の原因となったものや、今なおExecutiveを悩ませているものと同種の、役に立たない類のトラブルでしょう。興味のある方は、それぞれ4番目と6番目のレポートを参照してください。両機種についてはさらに多くの記事があるので、Linuxセクションもぜひご覧ください。

なぜカーネルの問題だと考えられるのか？　理由は、Kubuntu 22.04とVirtualBox 7.0の使用中に突然発生し始め、Kubuntu 24.04とVirtualBox 7.1に移行しても継続しているからです。「犯人はVirtualBoxだ」と言うこともできますが、それでは筆者がこれまで発見してきた数々のカーネルバグを説明できません。

実際、システムログには次のようなエラーが記録されていました：

kernel: unchecked MSR access error: WRMSR to 0xd10 (tried to write 0x000000000000ffff) at rIP: 0xffffffff910c6be4 (native_write_msr+0x4/0x40)
kernel: Call Trace:
kernel: <TASK>
kernel: ? show_stack_regs+0x23/0x40
kernel: ? ex_handler_msr+0x10a/0x180
...

「unchecked MSR access error: WRMSR」で検索すると、openSUSE、Fedora、Rocky、Ubuntu、Proxmoxなどに関連する何百ものスレッドが見つかります。明らかにカーネルの問題であり、報告は2019年まで遡りますが、その大半は未解決のままです。素晴らしいですね。

背景のコードを少し理解する必要がありますが、簡潔にまとめると次の通りです。サイドチャネル攻撃などへの対策としてカーネルに追加された各種緩和策により、カーネルのスケジューリング・コア管理と、同様の処理を行うサブシステム（ハイパーバイザーなど）との間で競合が生じる可能性があります。特に準仮想化とネステッドページングを使用している場合に顕著です。要するに、緩和策がやや攻撃的すぎるため、システムのフリーズやハングにつながることがあるのです。

余談ですが、これらのカーネル緩和策はエンタープライズ用途には100%関連しますが、家庭用途には0%しか関係ありません。しかしLinuxデスクトップはエンタープライズ／コーポレート向けカーネル世界の偶然の産物に過ぎないため、エンドユーザーであるあなたは、自宅のマシンで企業向けの問題に悩まされることになるのです。

回避策

この問題の発生頻度を抑える方法は3つあります。

仮想マシンに割り当てるCPUコア数を減らす

8コアなどを割り当ている場合は、1〜2コア、あるいは4コアに減らしてみてください。多少は改善しますが、問題が完全に解消されるわけではありません。

該当する仮想マシンでネステッドページングを無効にする

パフォーマンスは大幅に低下しますが、少なくとも仮想マシンは正常に動作し、システムがハングすることはなくなります。例えばVirtualBoxでは、「システム ＞ アクセラレーション」を開き、「ネステッドページングを有効化」のチェックを外します。

一般的に、以下のオプションを組み合わせて、どの設定が最適か試してみるとよいでしょう：

• プロセッサー ＞ 拡張機能 ＞ ネステッドVT-x/AMD-Vを有効化
• 準仮想化インターフェース（LinuxのデフォルトはKVM）
• ハードウェア仮想化 ＞ ネステッドページングを有効化

準仮想化（ネステッドページング）を無効にする

BIOS/UEFIから無効化する方法（マシン全体に適用されます）と、KVMハイパーバイザー用の設定ファイルを作成する方法（すべての仮想マシンでネステッドページングを禁止）があります。/etc/modprobe.d 配下に、CPUのアーキテクチャに応じて kvm-intel.conf または kvm-amd.conf というファイルを作成し、以下の内容を記述します：

options kvm-[amd|intel] nested=0

ハイパーバイザーのカーネルモジュールを再ロードするか（または再起動すれば）、MSRエラーのない環境が手に入ります。ただし、すべての仮想化ワークロードに速度低下をもたらすため、この方法はおすすめしません。必要に応じて個別の仮想マシンでネステッドページングのチェックを外す方が、より確実かつ手早い対応です。適切なカーネルパッチが登場して、この問題が恒久的に解決されることを期待しましょう。

まとめ

というわけで、Linuxデスクトップへの信頼をまた少し削ぎ落とす問題でした。この時点で、蓄積された苦痛はもはや滑稽なレベルに達しています。Linuxがモジュール式で柔軟なのは素晴らしいことですが、なぜ自分のデスクトップで、クラウド上の「悪意ある」テナントのことを気にかけなければならないのでしょうか？　気にしません。企業には、ビジネスの世界だけでなく（そもそもテストしているのかどうかも怪しいですが）、あらゆるシナリオでカーネルを検証することを期待したいところです。LinuxデスクトップのQAがお笑いレベルであることは周知の事実ですが、カーネルが何らかの動作をするなら、少なくとも最低限のテストはあるべきです。

筆者はこうした性質の問題が大嫌いです。何年も放置され、家庭用途には無関係な、散弾銃のような問題だからです。これらは無意味なリグレッションであり、日常の使用を難しくし、デスクトップ領域がいかに過度に複雑化しているか、そして本質的にはデスクトップではないことを浮き彫りにしています。せいぜい、GUIを載せた改悪版サーバーを使っていて、ホームユースと呼べる小さな特典がいくつか付いている程度です。実際、今後数週間のうちに、自分専用の小さなディストリビューションを組み立てて、これを実証する予定です。ええ、本当に。とにかく、仮想化の実行中にシステムがフリーズする場合は、ログを確認し、上記の回避策を試してみてください。問題が修正されるまで——それは永遠に来ないかもしれません。それでは、また。

それでは皆さん、よいLinuxライフを。