Windows Server 2019のHyper-V VmSwitch.sys ドライバーの内部処理の問題でBugCheck 0x139 エラーというちょっと気になる情報がフォーラムに書かれていました。
情報元はこちら。
Windows Server 2019 における vmswitch.sys ドライバーの BugCheck 0x139 エラーについて
以前、Hyper-Vに関するKBのバグもありましたし、安易にホストにパッチを適用すると問題が発生する可能性があり、本当に怖いですね。
Windows Server 2019 を Hyper-V ホストとして利用されている環境で発生する可能性のある BugCheck 0x139 エラーに関して、その事象と回避方法が紹介されています。※根本原因はまだ判明していないそうです。
1. Windows Server 2019 で Hyper-V の役割をインストールしている
2. 物理ネットワークアダプターが RSSv2 をサポートしている
3. RSS (または VMQ) の構成で Processor 0 を除外している
上の全ての条件に当てはまる場合に、VmSwitch.sys ドライバーの内部処理で問題が発生し BugCheck 0x139 が発生する場合があるとのことです。場合があるとのことで、再現度は100%ではなさそうです。
1は分かりやすいと思いますが、2はメーカーのドライバに依存しそうです。そして、3は確認ができます。
RSS (または VMQ) の構成で Processor 0 が除外されているかどうかを確認する方法
管理者として PowerShell を起動し、Get-NetAdapterRss コマンドレットを実行します。
出力結果の例として、当該部分を抜き出したものを以下に示します。
Name : Slot 01 Port 1
RssProcessorArray: [Group:Number/NUMA Distance] : 0:2/0 0:4/0 0:6/0
Name : Slot 01 Port 2
RssProcessorArray: [Group:Number/NUMA Distance] : 0:8/0 0:10/0 0:12/0
この出力結果の見方として、最初の番号が NUMA Group 番号、２番目が Processor 番号、３番目が NUMA の距離情報になります。
この事象に対して、有効性が確認されている回避策は、 RSS (VMQ) に Processor 0 を含める方法とのこと。
手順の抜粋です。
Processor 0を含んだ構成に変更するには、Set-NetAdapterRss PowerShell コマンドレットを使用します。
https://docs.microsoft.com/en-us/powershell/module/netadapter/set-netadapterrss?view=win10-ps
例えば、前述の例の場合であれば、以下のように指定します。
Set-NetAdapterRss -Name “Slot 01 Port 1” -BaseProcessorNumber 0 -MaxProcessorNumber 12
Set-NetAdapterRss -Name “Slot 01 Port 2” -BaseProcessorNumber 0 -MaxProcessorNumber 12
これにより全ての物理ネットワークアダプターについて Processor 番号の 0 から 12 までが利用されることになり、今回ご紹介した問題は解消されます。
なお、複数の物理ネットワークアダプターが存在する場合に、RSS (または VMQ)として割り当てる Processor 番号を重複しないように設定して負荷分散を行う方法がございますが、Windows Server 2019 では、複数物理ネットワークアダプターで Processor 番号がオーバーラップしている状態であっても、仮想ネットワークアダプターに対してオーバーラップしないよう適切に割り当てを行うよう緩和されていますので、物理ネットワークに対する Processor 番号の振り分けの考慮は特に必要ありません。
まだ、2019でHyper-Vホストを構成しているところは少ないとは思いますが、知っておいた方がいいですね。
 |
|
本棚 Vacplus 収納棚 大容量 収納ラック 組み立て式 整理棚 収納ボックス 衣類収納ボックス 多用途 耐久性 省スペース 収納便利 ホワイト 1個幅30×奥行30×高30? |
