Windows Server 2022で SET を組んだら、イベント ID 106が出ていた

Windows Server 2022で Switch Embedded Teaming（SET）を組んだら、イベント ID 106が出ていました。
※ログ保存するのを忘れて、クリーンインストールしたため、画面キャプチャ等は無しです。。。

Hyper-V 仮想スイッチが LBFO チームにバインドされている場合のイベント ID 106

Set-NetAdapterVmqで解決する方法が書かれています。が、そもそも Windows Server 2022で LBFO チームの上に仮想スイッチを作るのは非推奨（というか GUI からは許可されてない）です。よって、SET を一度解体し、LBFO を使わないように構成しました。下記がそのサンプルで、赤字箇所がLBFO を使わないオプションです。

$NICs = @("SLOT 1 ポート 1","SLOT 1 ポート 2","SLOT 1 ポート 3","SLOT 1 ポート 4")

$MngName = "Management"

$VSwName = "SET01"

New-VMSwitch -Name $VSwName -NetAdapterName $NICs -AllowManagementOS 0 -AllowNetLbfoTeams $false -EnableIov $true -EnableEmbeddedTeaming $true -Verbose

2023年1月22日　追記

上記の内容を訂正する記事を書きました。

Windows Server 2022でNew-VirtualSwitch の -AllowNetLbfoTeams オプションは、使わなくても大丈夫です。 

Windows Server 2022用の AVMA キーが公開されていますよ

AVMA keys

アクティベーション済みの Hyper-V ホスト上で稼働する仮想マシンをアクティベーションできるのが、AVMA keys です。

初見の方は、

Windows Server での仮想マシンの自動ライセンス認証

もご覧ください。

Windows Server 2022では、Teaming の上に仮想スイッチは作れません

 Windows Server 2019から、Windows Server 2022へインプレースアップグレードしてます。Windows Server 2019でTeaming の上に仮想スイッチを作っていたのですが、これが引っ掛かりました。これを解消しないとインストールできないことを申し添えます。

これは、インプレースアップグレードだけではありません。OSインストール後も同じように非推奨となります。

というわけで、Teaming の上に仮想スイッチは作れないため、Switch Embeded Teaming（SET）を使いましょう。

※シングル NIC の上に仮想スイッチを作るのは制約ないです。
　が、運用環境で、シングル NIC の上に仮想スイッチ作るのは冗長性が無いことから滅多に使わないとも思います。

Windows イメージが 4 GB を超える場合、install.wim ファイルを分割すればよいのか

Windows Server 2022のクリーンインストールを実施してます。

が、Windows Server 2022の Windows イメージ（install.wim ファイル）が 4 GB を超えてます。。。

かといって自宅内のNWだと、BMC 経由の ISO ファイルマウントは猛烈に遅い。

ほかに何か方法はないかと調べたら、下記がありました。

USB フラッシュ ドライブからの Windows のインストール

なんと、install.wim ファイルを分割すればよいのか、知らないのが恥ずかしい。。。

私の環境では、下記のコマンドラインで実行できました。
※ちなみに、終わるまで結構時間かかるようなので、気長に待ちましょう。
　結果の画面キャプチャ撮り忘れましたorz

robocopy f: d: /s /max:3800000000

Dism /Split-Image /ImageFile:f:\sources\install.wim /SWMFile:d:\sources\install.swm /FileSize:3800

結果として、このようにファイル分割できてます。

追伸　2021/09/03

別の用途で、install.wimを分割してみました。こんな感じの実行例です。
※上記とは、ドライブレターが異なります、ご注意くださいね。

ClusterPerformanceHistory/クラスターパフォーマンス履歴 がうまく取得できないし

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/performance-history-scripting#sample-3-noisy-neighbor-thats-write

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/performance-history-for-vhds

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/performance-history-for-vms

を参考にスクリプトを書いています。

ちょっと困ったことが起きました。仮想マシンは実行中なのにデータが取れてない！

ClusterPerformanceHistory がもしかしておかしくなった？！　と思いましたので、

• Stop-ClusterPerformanceHistory
• Start-ClusterPerformanceHistory

を実行してみます。

再び、クラスターパフォーマンス履歴から仮想マシンの情報を取得してみます。

やっぱりだめだ。

• Stop-ClusterPerformanceHistory -DeleteHistory
• Start-ClusterPerformanceHistory

を実行！

ちょっと警告が出ていますが、仮想マシンの情報は取れるようになりました！

CentOS 7.8の仮想マシンを追加して、再度、クラスターパフォーマンス履歴から仮想マシンの情報を取得します。

今度は、仮想マシンの情報を取得は、両方とも取れました。ただ CentOS 7.8のMemoryUsagePercent の値が違うけどなぁ。。。Windows と扱いが違うのかしら。

Dell EMC OpenManage Integration with Microsoft Windows Admin Centerに必要なポート

Dell EMC OpenManage Integration 2.1.0がリリースされてます。というわけで、

Dell EMC OpenManage Integration with Microsoft Windows Admin Centerに必要なポート

で必要なポートをチェックしてます。

特筆すべきなのは、「ターゲットホスト=管理対象・監視対象の物理サーバー」の受信ポートで445を開けておく必要がありますね。
あと、iDRAC 用に 443、WinRM 用に5985が必要です。

2021/11/09 追記

「ターゲットホスト=管理対象・監視対象の物理サーバー」の管理共有にもアクセスします。

仮想マシンのマイグレーションで使用するポート

FW で分離されたネットワークセグメントへ、仮想マシンのクラスター間マイグレーションができない。
※解決に向けて鋭意調査中です。

SCVMM をコントローラーにしています。ちなみに、FW で分離されていないネットワークセグメントでは、何も問題なく仮想マシンのクラスター間マイグレーションできてます。ということで、FW の許可 ACL が足りないと推測。

VMM のポートとプロトコルの特定 に VMM 自体の許可ポートは、記載されています。

が、SCVMM から FW で分離されたネットワークセグメントにいる Hyper-V ホストへの通常操作は問題ないです。つまり、VMM のポートとプロトコルの特定 に記載されているポートは、FW で解放されているわけです。

よって、VMM のポートとプロトコルの特定 以外のポートがないかを特定しないといけません。

で、その候補と考えているのが、以下です。
※今回は、ライブ移行ではないのですが、関係しそうかなと。

ライブ移行の問題のトラブルシューティング

に TCP ポート 6600 と 3343 の疎通が必要とあります。

さて、この推測は、あっているのか？！

追記）コメントにも書きましたが、推測あってました。