Windows Server 2022でNew-VirtualSwitch の -AllowNetLbfoTeams オプションは、使わなくても大丈夫です。
という訂正記事を書いたついでに、「Azure Stack HCI OS 22H2でもNew-VirtualSwitch の -AllowNetLbfoTeams オプションは、使わなくても大丈夫ということだよね」を念のため確認しておきます。
Azure Stack HCI OS 22H2に、最新のパッチを適用してから確認を始めました。
イベントID 106がないことを確認しておきます。
Azure Stack HCI OS 22H2でNew-VirtualSwitch の -AllowNetLbfoTeams オプションを使わずに、SETを作成します。
※合わせて、マネジメント用のvNICを作成し、IPアドレスやDNSサーバー情報を設定しておきます。
イベントID 106がないはずですが、念のため確認しておきます。
以前、下記のような記事を書きました。
Windows Server 2022でNew-VirtualSwitch の -AllowNetLbfoTeams オプションを使わずに、SETを作成します。
※合わせて、マネジメント用のvNICを作成し、IPアドレスやDNSサーバー情報を設定しておきます。
Windows Server 2022で、New-VirtualSwitch の -AllowNetLbfoTeams オプションを使わなずとも、AllowNetLbfoTeamsはfalseになっていました！
イベントID 106がないはずですが、念のため確認しておきます。
従って、下記ドキュメントに、-AllowNetLbfoTeams オプションが書いてなくても大丈夫です。知識をリフレッシュできて一安心！
Switch Embedded Teaming (SET)の負荷分散モード（負荷分散アルゴリズム）は Hyper-V Port になっているかを確認（振り返る）します。
下記のような感じで、SET を作ってました。
下記のような感じで、SET を作ってました。
最初に結論から申し上げますと、適合しません。
Windows Server 2022で SET を組んだら、イベント ID 106が出ていた
の続きかも。
試しに、Windows Server 2019で、-AllowNetLbfoTeams オプションを付けて、New-VirtualSwitch で Switch Embedded Teaming（SET）を作ろうとすると失敗します。
また Windows Server 2022の New-VMSwitch は、まだプレビュー版の記載のため、言及無し。後日、Windows Server 2022の New-VMSwitch を確認してみます。
2023年1月22日 追記
上記の内容を訂正する記事を書きました。
Windows Server 2022でNew-VirtualSwitch の -AllowNetLbfoTeams オプションは、使わなくても大丈夫です。
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 2019から、Windows Server 2022へインプレースアップグレードしてます。Windows Server 2019でTeaming の上に仮想スイッチを作っていたのですが、これが引っ掛かりました。これを解消しないとインストールできないことを申し添えます。
これは、インプレースアップグレードだけではありません。OSインストール後も同じように非推奨となります。
というわけで、Teaming の上に仮想スイッチは作れないため、Switch Embeded Teaming（SET）を使いましょう。
※シングル NIC の上に仮想スイッチを作るのは制約ないです。同僚の方より、Hyper-V vSwitch における負荷分散フェールオーバー (LBFO)は、Azure Stack HCI でのサポートが無いようだと聞きました。
教えてもらった情報
を読んでみました。上記から本文を引用しますと、
SET は、Azure Stack HCI でサポートされている唯一のチーミング テクノロジです。 負荷分散フェールオーバー (LBFO) は、Windows Server で一般的に使用される別のチーミング テクノロジですが、Azure Stack HCI ではサポートされていません。
とありますね。。。
ほかにも、下記の情報を教えていただきました。
Teaming in Azure Stack HCI より本文を引用します。
All-in-all, we’re not focusing on LBFO much these days, particularly as software-defined Windows Server networking scenarios become more exotic with the rise of containers, software-defined networking, and much more. There’s a faster, more stable, and performant teaming solution, called Switch Embedded Teaming.
Features we're no longer developing より本文を引用します。
Hyper-V vSwitch on LBFO In a future release, the Hyper-V vSwitch will no longer have the capability to be bound to an LBFO team. Instead, it must be bound via Switch Embedded Teaming (SET).
これらを見ていくと、今後は スイッチが埋め込まれたチーミング/Switch Embedded Teaming (SET)を主流にしていくのかなと思います。
例えば。
Windows Admin Center において、 Azure Stack HCI OSを使ったクラスター作成では、SET を使っていくようになっています。
※もちろん、Azure Stack HCI OS は、Storage Spaces Direct (S2D)です。ストレージ同期ジョブに高速なネットワークを使います。その高速なネットワークを通すためには、SET が最適というのも理由でしょう。
SET は、PowerShell で作成しますので、このあたりの押さえておくべき技術になるのかもしれませんね。
Azure Stack HCI OS ノードを追加する前に Switch Embedded Teaming (SET) 仮想スイッチをそろえておきたいと思いました。
二つの SET を作成するパターンで、構築してました。
Windows Admin Center の Cluster Creation で Azure Stack HCI を組む その2
上記で作成した SET は、二つあります。Hyper-V の仮想スイッチマネージャーで見てみます。
ホスト OS への管理ネットワークアダプターは、普通に作れるとして、SRIOV のオプションが有効化されるかも確認点となります。
早速、Windows Admin Center で作成してみました。
NIC が全部入っているし、SETになってない。。。
というわけで、PowerShell で仮想スイッチを作り直します。とりあえず、どういう感じで構成されているのか、Windows Admin Center から確認しておきます。
作成できました。GUI から違いが無いか見てみます。
SR-IOV が有効になってない。
-EnableIov $true を追加して作り直します。
今度は大丈夫です。
※ちなみに、-EnableEmbeddedTeaming $true が既定になっているような感じで、このオプションがなくても SET になっているような。
Get-VMswitch から違いがないか、diff チックに確認してみます。
違いがありますね。。。どちらの仮想スイッチで差異があるのか確認します。
に違いがありました。
プロパティを変更できるかやってみます。
読み取り専用のため、できない。。。
set-VMswitch を見てみましたが、変更できるプロパティではないようですね。。。
ということで、Windows Admin Center のクラスター作成 と、PowerShell による SET 作成では、一部のプロパティに差異があります。これを防ごうとすると、事前に PowerShell で SET 作成し、Windows Admin Center のクラスター作成に進むのがよさそうです。
この仮説が可能なのかを確認してみます。別稿に続く。
