Hyper-V によるハイパーバイザー スケジューラの種類の選択について
適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server バージョン 1709、Windows Server バージョン 1803
このドキュメントでは、Hyper-V によるハイパーバイザー スケジューラの種類の既定の使用法と推奨される使用法に対する重要な変更について説明します。 これらの変更は、システムのセキュリティと仮想化のパフォーマンスの両方に影響します。 仮想化ホスト管理者は、このドキュメントで説明されている変更と影響を確認して理解し、影響、推奨される展開ガイダンス、および関係するリスク要因を慎重に評価して、急速に変化するセキュリティ環境に直面したときに Hyper-V ホストを展開して管理する方法について可能な限り深く理解する必要があります。
重要
現在、従来のハイパーバイザー クラシック スケジューラの種類を、同時マルチスレッド (SMT) が有効になっているホストで実行した場合、複数のプロセッサ アーキテクチャで見つかっている既知のサイドチャネル セキュリティ脆弱性が、悪意のあるゲスト VM によって、スケジューラのスケジュール動作を通じて悪用される可能性があります。 悪用が成功した場合、悪意のあるワークロードによって、データがそのパーティション境界の外で観察される可能性があります。 このクラスの攻撃は、ハイパーバイザー コア スケジューラの種類を利用するように Hyper-V ハイパーバイザーを構成し、ゲスト VM を再構成することにより、軽減することができます。 コア スケジューラを使用すると、ゲスト VM の VP の実行はハイパーバイザーによって同じ物理プロセッサ コア上に制限されるため、VM のデータ アクセス機能は、それが実行されている物理コアの境界に強力に分離されます。 これは、このようなサイドチャネル攻撃に対する非常に効果的な軽減策であり、ルート パーティションか別のゲスト パーティションかに関係なく、VM から他のパーティションの成果物を観察することはできなくなります。 そのため、Microsoft は仮想化ホストとゲスト VM の既定の構成設定と推奨される構成設定を変更しています。
背景
Windows Server 2016 以降の Hyper-V では、仮想プロセッサをスケジュールおよび管理する複数の方法がサポートされており、ハイパーバイザー スケジューラの種類と呼ばれます。 ハイパーバイザー スケジューラのすべての種類の詳細については、Hyper-V ハイパーバイザーのスケジューラの種類の理解と使用に関する記事をご覧ください。
注意
新しいハイパーバイザー スケジューラの種類は、Windows Server 2016 で初めて導入され、それより前のリリースでは使用できません。 Windows Server 2016 より前のすべてのバージョンの Hyper-V では、クラシック スケジューラのみがサポートされています。 コア スケジューラのサポートは、最近公開されたばかりです。
ハイパーバイザー スケジューラの種類について
この記事では、新しいハイパーバイザー コア スケジューラの種類と従来の "クラシック" スケジューラの使用、およびこれらのスケジューラの種類が対称マルチスレッド (SMT) の使用とどのように関係するかについて特に焦点を当てます。 コア スケジューラとクラシック スケジューラの違い、およびそれぞれがゲスト VM の処理を基になるシステム プロセッサでどのように実行するのかを理解することが重要です。
クラシック スケジューラ
クラシック スケジューラとは、ルート仮想プロセッサ (VP) やゲスト VM に属する VP も含めたシステム全体の VP で処理をスケジュールする、公平なラウンド ロビン方式のことです。 クラシック スケジューラは、すべてのバージョンの Hyper-V で使用される既定のスケジューラの種類です (ここで説明するように、Windows Server 2019 まで)。 クラシック スケジューラのパフォーマンス特性は十分に理解されており、クラシック スケジューラは、ワークロードのオーバーサブスクリプションを適切に、つまりホストの VP:LP 比のオーバーサブスクリプションを妥当なマージンで (仮想化されるワークロードの種類、全体的なリソース使用率などに応じて)、サポートすることが示されています。
SMT が有効になっている仮想化ホストで実行すると、クラシック スケジューラは、任意の VM からのゲスト VP を、コアに属する各 SMT スレッドに個別にスケジュールします。 したがって、異なる VM が同じコアで同時に実行できます (ある VM はコアの 1 つのスレッドで実行し、別の VM は他のスレッドで実行します)。
コア スケジューラ
コア スケジューラは、SMT のプロパティを利用してゲスト ワークロードの分離を提供し、セキュリティとシステムのパフォーマンスの両方に影響を与えます。 コア スケジューラにより、1 つの VM の複数の VP は兄弟 SMT スレッドでスケジュールされることが保証されます。 これは対称型で実行されるため、LP が 2 つのグループに含まれている場合、VP は 2 つのグループにスケジュールされ、システムの CPU コアが VM 間で共有されることはありません。
コア スケジューラは、基になる SMT ペアでゲスト VM をスケジュールすることで、ワークロードの分離のための強力なセキュリティ境界を提供し、待機時間の影響を受けやすいワークロードのパフォーマンスの変動を減らすためにも使用できます。
SMT が有効になっていない仮想マシンに対して VP をスケジュールすると、その VP は実行時にコア全体を消費し、コアの兄弟 SMT スレッドはアイドル状態のままになることに注意してください。 これは、ワークロードを適切に分離するために必要なことですが、システム全体のパフォーマンスに影響し、システムの LP がオーバーサブスクライブされるとき (つまり、合計 VP:LP 比率が 1:1 を超える場合) は特にそうです。 そのため、コアごとに複数のスレッドを使用せずに構成されたゲスト VM を実行することは、最適な構成ではありません。
コア スケジューラを使用する利点
コア スケジューラには、次の利点があります。
ゲスト ワークロードの分離のための強力なセキュリティ境界 - ゲスト VP は、基にとなる物理コアのペアで実行するように制約されるため、サイドチャネル スヌーピング攻撃に対する脆弱性が軽減されます。
ワークロードの変動の軽減 - ゲスト ワークロードのスループットの変動が大幅に減少し、ワークロードの一貫性が向上します。
ゲスト VM での SMT の使用 - ゲスト仮想マシンで実行される OS とアプリケーションは、SMT の動作とプログラミング インターフェイス (API) を利用して、仮想化されずに実行される場合と同様に、SMT スレッド間で処理を制御および分散できます。
コア スケジューラは、現在、特に強力なセキュリティ境界とワークロードの低い変動性を利用するために、Azure 仮想化ホストで使用されています。 Microsoft は、仮想化シナリオの大部分に対してはコア スケジューラの種類を既定のハイパーバイザー スケジューリングの種類にする必要があり、今後もそうであり続けると考えます。 したがって、Microsoft は、お客様が既定でセキュリティ保護されるよう、現在、Windows Server 2019 に対してこの変更を行っています。
ゲスト ワークロードのパフォーマンスに対するコア スケジューラの影響
コア スケジューラは、特定のクラスの脆弱性を効果的に軽減するために必要ですが、パフォーマンスを低下させる可能性もあります。 お客様は、VM のパフォーマンス特性の違いと、仮想化ホストの全体的なワークロード容量への影響を、認識する可能性があります。 コア スケジューラで SMT ではない VP を実行する必要がある場合は、基になる論理コア内の命令ストリームの 1 つだけが実行され、それ以外はアイドル状態のままになるようにする必要があります。 これにより、ゲスト ワークロードのホスト容量の合計が制限されます。
このようなパフォーマンスへの影響は、このドキュメントの展開ガイダンスに従うことで最小限にできます。 ホスト管理者は、特定の仮想化展開シナリオを慎重に検討し、最大ワークロード密度や仮想化ホストの過剰統合などの必要性に対して、セキュリティ リスクの許容度のバランスを取る必要があります。
Windows Server 2016 と Windows Server 2019 での既定の構成と素賞される構成に対する変更点
最大限のセキュリティ態勢で Hyper-V ホストを展開するには、ハイパーバイザーのコア スケジューラの種類を使用する必要があります。 既定の状態でお客様が確実にセキュリティ保護されるよう、Microsoft は次の既定の設定と推奨設定を変更しています。
注意
ハイパーバイザーによるスケジューラの種類の内部サポートは Windows Server 2016 の初期リリース、Windows Server 1709、Windows Server 1803 において組み込まれましたが、ハイパーバイザーのスケジューラの種類を選択できる構成制御にアクセスするには、更新プログラムが必要です。 これらの更新プログラムの詳細については、Hyper-V ハイパーバイザーのスケジューラの種類の理解と使用に関する記事をご覧ください。
仮想化ホストに関する変更点
Windows Server 2019 以降では、コア スケジューラがハイパーバイザーによって既定で使用されるようになります。
Microsoft は、Windows Server 2016 でコア スケジューラを構成することをお勧めします。 Windows Server 2016 では、ハイパーバイザーのコア スケジューラの種類はサポートされていますが、既定の設定はクラシック スケジューラです。 コア スケジューラはオプションであり、Hyper-V ホスト管理者が明示的に有効にする必要があります。
仮想マシンの構成に関する変更点
Windows Server 2019 では、既定の VM バージョン 9.0 を使用して作成された新しい仮想マシンは、仮想化ホストの SMT プロパティ (有効または無効) を自動的に継承します。 つまり、物理ホストで SMT が有効になっている場合、新しく作成される VM でも SMT が有効になり、ホストの SMT トポロジが既定で継承され、VM のコアあたりのハードウェア スレッドの数は基になるシステムと同じになります。 これは、HwThreadCountPerCore = 0 によって VM の構成に反映されます。0 は、VM がホストの SMT の設定を継承する必要があることを示します。
VM バージョン 8.2 以前の既存の仮想マシンでは、HwThreadCountPerCore について元の VM のプロセッサの設定が維持され、VM バージョン 8.2 のゲストの既定値は HwThreadCountPerCore = 1 です。 これらのゲストを Windows Server 2019 のホストで実行すると、次のように扱われます。
VM の VP の数が、LP コアの数以下である場合、VM はコア スケジューラによって SMT ではない VM として扱われます。 ゲスト VP が単一の SMT スレッドで実行されると、コアの兄弟 SMT スレッドはアイドル状態になります。 これは最適ではないので、全体的なパフォーマンスが低下します。
VM の VP が LP コアより多い場合、VM はコア スケジューラによって SMT VM として扱われます。 ただし、それが SMT VM であることを示す他の兆候が VM によって観察されることはありません。 たとえば、OS やアプリケーションが CPUID 命令または Windows API を使用して CPU のトポロジを照会しても、SMT が有効であることは示されません。
Update-VM 操作によって既存の VM を以前の VM バージョンからバージョン 9.0 に明示的に更新する場合、VM は HwThreadCountPerCore の現在の値を保持します。 VM で SMT が強制的に有効になることはありません。
Windows Server 2016 では、ゲスト VM に対して SMT を有効にすることをお勧めします。 Windows Server 2016 で作成される VM では、明示的に変更しない限り、SMT は既定で無効になります。つまり、HwThreadCountPerCore は 1 に設定されます。
注意
Windows Server 2016 では、HwThreadCountPerCore を 0 に設定することはサポートされていません。
仮想マシンの SMT の構成の管理
ゲスト仮想マシンの SMT の構成は、VM ごとに設定されます。 ホスト管理者は、VM の SMT の構成を調べて構成し、次のオプションから選択できます。
SMT 有効として実行されるように VM を構成し、必要に応じてホストの SMT トポロジを自動的に継承します
非 SMT として実行するように VM を構成します
VM の SMT の構成は、Hyper-V マネージャー コンソールの [概要] ペインに表示されます。 VM の SMT 設定の構成は、[VM 設定] または PowerShell を使用して行うことができます。
PowerShell を使用した VM SMT の設定の構成
ゲスト仮想マシンの SMT の設定を構成するには、十分なアクセス許可で PowerShell ウィンドウを開き、次のように入力します。
Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>
各値の説明:
0 = ホストから SMT のトポロジを継承します (HwThreadCountPerCore=0 のこの設定は、Windows Server 2016 ではサポートされていません)
1 = 非 SMT
値 > 1 = コアあたりの必要な SMT スレッド数。 コアあたりの物理 SMT スレッドの数を超えることはできません。
ゲスト仮想マシンの SMT の設定を確認するには、十分なアクセス許可で PowerShell ウィンドウを開き、次のように入力します。
(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore
HwThreadCountPerCore = 0 で構成されたゲスト VM は、SMT がゲストで有効になること、および基になる仮想化ホストと同じ数の SMT スレッド (通常は 2) がゲストに公開されることを示します。
ゲスト VM で VM モビリティ シナリオ全体の CPU トポロジの変更が観察される場合がある
VM 内の OS とアプリケーションでは、ライブ マイグレーションや保存と復元操作などの VM ライフサイクル イベントの前と後に、ホストと VM 両方の設定に対する変更が認識される場合があります。 VM の状態が保存および復元される操作の間に、VM の HwThreadCountPerCore の設定と実現された値 (つまり、VM の設定とソース ホストの構成の計算された組み合わせ) の両方が移行されます。 移行先ホストの VM では、でこれらの設定が引き続き実行されます。 VM がシャットダウンされて再起動される時点で、VM によって観察される実現された値が変更される可能性があります。 OS およびアプリケーション レイヤーのソフトウェアは、通常の起動と初期化のコード フローの一部として CPU のトポロジ情報を検索する必要があるので、これは問題にはならないはずです。 しかし、ライブ マイグレーションまたは保存と復元操作のときはこれらの起動時初期化シーケンスがスキップされるため、これらの状態遷移の対象となる VM では、シャットダウンされて再起動されるまで、元の計算された実現値が観察される可能性があります。
最適でない VM 構成に関するアラート
ホストに存在する物理コアより多くの VP が構成された仮想マシンは、最適ではない構成になります。 ハイパーバイザー スケジューラは、このような VM を SMT 対応として扱います。 ただし、VM 内の OS とアプリケーション ソフトウェアには、SMT が無効になっていることを示す CPU トポロジが提示されます。 この状態が検出されると、Hyper-V ワーカー プロセスによって、VM の構成が最適ではないことをホスト管理者に警告し、VM に対して SMT を有効にすることを推奨する仮想化ホストでのイベントが、ログに記録されます。
最適ではない構成の VM を識別する方法
イベント ビューアーのシステム ログで、Hyper-V ワーカー プロセスのイベント ID 3498 を調べることで、SMT ではない VM を特定できます。これは、VM 内の VP の数が物理コア数より大きいとき常に、VM に対してトリガーされます。 ワーカー プロセスのイベントは、イベント ビューアーから、または PowerShell を使用して取得できます。
PowerShell を使用した Hyper-V ワーカー プロセスの VM イベントの照会
PowerShell を使用して Hyper-V ワーカー プロセスのイベント ID 3498 を照会するには、PowerShell プロンプトから次のコマンドを入力します。
Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-Worker"; ID=3498}
ゲスト オペレーティング システムに対するハイパーバイザー エンライトメントの使用へのゲスト SMT 構成の影響
Microsoft のハイパーバイザーでは、複数のエンライトメント (ヒント) が提供されます。ゲスト VM で実行されている OS でこれを照会して、パフォーマンスの向上や、仮想化実行時のさまざまな条件の処理の改善といった最適化をトリガーするために使用できます。 最近導入されたエンライトメントの 1 つは、仮想プロセッサのスケジュール設定の処理と、SMT を悪用するサイドチャネル攻撃に対する OS の軽減策の使用に関するものです。
注意
Microsoft はホスト管理者に、ゲスト VM の SMT を有効にして、ワークロードのパフォーマンスを最適化することをお勧めします。
このゲスト エンライトメントの詳細については、以下を参照してください。ただし、仮想化ホスト管理者にとって重要なのは、ホストの物理的な SMT 構成と一致するように、仮想マシンの HwThreadCountPerCore を構成する必要があるということです。 これにより、ハイパーバイザーは、アーキテクチャによらないコアの共有がないことを報告できます。 そのため、エンライトメントを必要とする最適化をサポートするすべてのゲスト OS が有効になっている可能性があります。 Windows Server 2019 では、新しい VM を作成し、HwThreadCountPerCore を既定値 (0) のままにします。 Windows Server 2016 ホストから移行された古い VM は、Windows Server 2019 構成バージョンに更新できます。 それを行った後、HwThreadCountPerCore = 0 を設定することをお勧めします。 Windows Server 2016 では、ホストの構成と一致するように HwThreadCountPerCore を設定することをお勧めします (通常は 2)。
NoNonArchitecturalCoreSharing エンライトメントの詳細
Windows Server 2016 以降のハイパーバイザーでは、VP のスケジューリングの処理とゲスト OS への配置を説明する新しいエンライトメントが定義されています。 このエンライトメントは、ハイパーバイザー トップ レベル機能仕様 v5.0c で定義されています。
ハイパーバイザー統合 CPUID リーフ CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] は、兄弟 SMT スレッドとして報告される仮想プロセッサを除き、仮想プロセッサが物理コアを別の仮想プロセッサと共有しないことを示します。 たとえば、ゲスト VP は、同じプロセッサコア上の兄弟 SMT スレッドで同時に実行されているルート VP と共に、1 つの SMT スレッドで実行されることはありません。 この条件は、仮想化されて実行されている場合にのみ可能であり、セキュリティに深刻な影響を与えるアーキテクチャ以外の SMT 動作を表します。 ゲスト OS では、NoNonArchitecturalCoreSharing = 1 を使用して、最適化を有効にしても安全であることを示すことができます。これにより、STIBP を設定することによるパフォーマンスのオーバーヘッドを回避できます。
特定の構成では、ハイパーバイザーによって NoNonArchitecturalCoreSharing = 1 が示されません。 たとえば、ホストで SMT が有効になっていて、ハイパーバイザー クラシック スケジューラを使用するようにホストが構成されている場合、NoNonArchitecturalCoreSharing は 0 になります。 これにより、エンライトメントを受け取ったゲストが特定の最適化を有効にできない可能性があります。 したがって、SMT を使用するホスト管理者には、ワークロードのパフォーマンスが最適になるよう、ハイパーバイザー コア スケジューラに依存し、ホストから SMT の構成を継承するよう仮想マシンが構成されようにすることをお勧めします。
まとめ
セキュリティの脅威の状況は進化し続けています。 既定の状態でお客様がセキュリティ保護されるようにするため、Microsoft は Windows Server 2019 以降の Hyper-V でハイパーバイザーと仮想マシンの既定の構成を変更しており、Windows Server 2016 の Hyper-V を実行しているお客様には最新のガイダンスと推奨事項を提供しています。 仮想化ホスト管理者は、次のようにする必要があります。
このドキュメントに記載されているガイダンスを読んで理解します
仮想化の展開を慎重に評価して調整し、固有の要件に対するセキュリティ、パフォーマンス、仮想化の密度、ワークロードの応答性の目標が満たされるようにします
ハイパーバイザー コア スケジューラによって提供される強力なセキュリティの利点を利用するため、既存の Windows Server 2016 Hyper-V ホストを再構成することを検討します
既存の非 SMT VM を更新し、ハードウェア セキュリティの脆弱性に対処する VP 分離によって発生するスケジューリングの制約によるパフォーマンスへの影響を軽減します
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示