知らぬ間に進化を続けるHyper-V：その知識、ホントに正しい？ Windowsにまつわる都市伝説（201）

Windowsが標準でサポートするハイパーバイザーといえば「Hyper-V」です。Windows Server 2008（x64）で初めて登場してからしばらくは、新機能追加や機能強化が次々に行われました。しかし、Windows Server 2016以降、目に見える劇的な変化というものが少なくなったような気がしませんか。

[山市良，テクニカルライター]

Windowsにまつわる都市伝説

仮想マシンのプロセッサリソースコントロールがいつの間にか不能に？

　「Windows Server 2008」で初めて登場した「Hyper-V」は、短時間で大幅な機能強化が行われてきました。例えば、「Windows Server 2008 R2 Service Pack（SP）1」のHyper-Vでは、「RemoteFX 3Dビデオアダプター」（「Windows Server 2016」以降ではセキュリティ上の理由で廃止されました）や「USBデバイスリダイレクト」といった仮想デスクトップインフラストラクチャ（VDI）機能が強化されました。

　「Windows Server 2012」では、新しい仮想ハードディスク「VHDX」が登場し、また、「SLAT（Second Level Address Translation）」や「SR-IOV（Single Root I/O Virtualization）」「VMQ（Virtual Machine Queue）」などのハードウェアオフロード技術を活用した、メモリ、プロセッサ、ネットワークのパフォーマンス向上が可能になりました。

　「Windows Server 2012 R2」では、UEFIベースの第2世代仮想マシンが登場し、エミュレートされたデバイスに多く依存していた従来の第1世代仮想マシンとは異なり、仮想マシンの準仮想化（仮想化を認識して、最適化）レベルが向上しました。

　そして、Windows Server 2016では、「入れ子になった仮想化（Nested Virtualization）」や「個別デバイスの割り当て」（DDA《Discrete Device Assignment》、PCI Expressデバイスを直接仮想マシンに割り当てる機能）がサポートされました。

　しかし、「Windows Server 2019」以降、機能の廃止（RemoteFX 3Dビデオアダプターや古い仮想マシン構成バージョンの廃止など）はあっても、目玉といえる新機能が登場していないように思えます。「Windows Server 2022」のHyper-Vで、AMDプロセッサでもようやく入れ子になった仮想化がサポートされましたが、それくらいです。

　実は、見えないところで重要な変更が行われていたりします。今回はそんな重要な変更の一つである「ハイパーバイザーのプロセッサスケジューラ」の話をしましょう。筆者もつい最近まで気が付いていませんでした。

　きっかけは、「Windows 10」のHyper-Vで仮想マシンの設定を眺めていたときのことです。Hyper-Vはその登場時から、プロセッサリソースが競合したときにリソース配分を調整する「リソースコントロール」という機能がありました。

　Hyper-Vが仮想マシンに提供する仮想プロセッサは、既定で全ての仮想マシンへ公平に配分されるため、状況によっては複数の仮想マシンが“俺が俺が”“どうぞどうぞ”状態になってしまう可能性があります。リソースコントロールは、そうした状況を打開するための調整役なのですが、現在のWindows 10ではこのオプションを有効化できない旨のメッセージが表示されます（画面1）。

画面1　Windows 10でリソースコントロールを利用できない

Windows 10 バージョン1803以降の既定はルートスケジューラ

　表示されたメッセージ下のリンクをクリックすると、以下のページにリダイレクトされます。

• Managing Hyper-V hypervisor scheduler types［英語］（Microsoft Docs）
• Hyper-Vハイパーバイザーのスケジューラの種類の管理［機械翻訳を含む］（Microsoft Docs）

　ドキュメントを見ると、Windows 10 バージョン1803以降、Windows 10の既定は「ルートスケジューラ」に変更されたことが分かります。そして、リソースコントロールオプションは、従来のスケジューラである「クラシックスケジューラ」でのみ利用可能であることが分かります。

　Windows 10にルートスケジューラが導入された理由は、仮想マシン以外の目的でハイパーバイザーが使用される場面が多くなったからです。

　例えば、「Docker Desktop」はWindowsコンテナのための分離環境を、「Microsoft Defender Application Guard」（旧称、Windows Defender Application Guard（WDAG）」は「Microsoft Edge」の分離環境を、「Windowsサンドボックス」はWindowsデスクトップの分離環境を、「Windows Subsystem for Linux（WSL）2」は本物のLinuxカーネルを提供するために、全てハイパーバイザーの仮想マシン環境を利用しています。

　また、「仮想化ベースのセキュリティ（Hypervisor-based Security、VBS）」は、その他の高度なセキュリティ機能（デバイスガードや資格情報ガード、分離ユーザーモードなど）を提供するために、ハイパーバイザーの仮想マシン環境を利用しています。

　仮想マシン以外のこれらの機能は、仮想マシン環境（「ユーティリティVM」とも呼ばれます）に対してルートパーティション側から行われる操作で機能する場合があります。そのため、ルートパーティション（ホストOS側）にスケジュールの役割を残しているというわけです。

　スケジューラの種類は、以下のコマンドを管理者として実行することで変更できます。「<タイプ>」には「classic」「core」（後述）、または「root」を指定します。例えば、いずれかのスケジューラに重大な脆弱（ぜいじゃく）性問題が見つかった場合は、変更する必要が出てくるかもしれません。

bcdedit /set hypervisorschedulertype <タイプ>

　また、スケジューラの種類は、イベントログのシステムログ、イベントソース「Hyper-V-Hypervisor」、イベントID「2」で確認することができます。「クラシック（SMT無効）」「クラシック」「コア」（後述）、「ルート」が、それぞれ「1」「2」「3」「4」に対応します（画面2）。

画面2　ルートスケジューラ（既定、4）をクラシックスケジューラ（1）に変更したWindows 10のイベントログの変化

Windows Server 2019以降の既定はSMT対応のコアスケジューラ

　前出のドキュメントには、Windows Serverにおけるスケジューラの変更についても説明されています。Windows Server 2019以降の既定は「コアスケジューラ」に変更され、Windows Server 2016はオプションでコアスケジューラに変更可能になっています（2018年7月のオプションの累積更新プログラム、ビルド14393.2395以上でサポート）。

　コアスケジューラは、新しいプロセッサが対応していることが多い、同時マルチスレッディング（SMT）に最適化されたスケジューラで、従来のスケジューラとSMTとの組み合わせで問題となるパフォーマンスの低下の変動を軽減するとともに、仮想マシンに対してプロセッサのSMT機能を公開（または非公開）することができるそうです。

　また、コアスケジューラによるプロセッサコアの境界の分離は、2018年1月に公表された「投機的実行のサイドチャネルの脆弱性」に対する緩和策としても重要な意味があります。以下のドキュメントにも、ハイパースレッディング（HT、IntelのSMT機能）を有効にしたままで、脆弱性を緩和する手段としてコアスケジューラが説明されています。コアスケジューラがWindows Server 2016にもバックポートされた理由もこれに違いありません。

• Windows を投機的実行のサイドチャネルの脆弱性から保護するためのガイダンス（Microsoft サポート）

　筆者が自宅で使用している検証用サーバのIntelプロセッサは、残念ながらSMT（HT）に対応していないモデルであり、そのサーバで稼働するWindows Server 2022のHyper-Vのスケジューラはクラシックスケジューラ（SMT無効、1）でした。入れ子になった仮想化に対応したAzure仮想マシンで確認してみると、確かにコアスケジューラ（3）になっていました（画面3）。また、入れ子になった仮想化でコアスケジューラが自動選択されたということは、Microsoft Azureの基盤が仮想マシンにSMT機能を既定で公開していることも意味しています（画面4）。

画面3　筆者の評価／テスト用サーバのIntelプロセッサはHT非対応であり、クラシックスケジューラ（SMT無効、1）が自動選択されていた

画面4　入れ子になった仮想化をサポートするAzure仮想マシンにWindows Server 2019をデプロイし、Hyper-Vを有効にすると、コアスケジューラ（3）が自動選択された

　最後に、今回紹介したハイパーバイザーのスケジューラは、特に理由がなければ自動選択された既定のままで使用するのが、パフォーマンスとセキュリティの両面にとって最適だと思います（要件によっては、スケジューラの変更やハイパースレッディングの無効化が適している場合もあるようです）。ただし、未パッチの脆弱性が明らかになり、その回避策としてスケジューラの変更が有効である場合が出てくるかもしれません。そのときに備えて、頭の隅にでも覚えておくとよいでしょう。

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP 2009 to 2022（Cloud and Datacenter Management）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker＆Windowsコンテナーテクノロジ入門』（日経BP社）、『ITプロフェッショナル向けWindowsトラブル解決 コマンド＆テクニック集』（日経BP社）。