Windows Server ソフトウェア定義ネットワーク スタックのトラブルシューティング

  • [アーティクル]

このガイドでは、一般的なソフトウェア定義ネットワーク (SDN) のエラーとエラーのシナリオを調べ、使用可能な診断ツールを使用するトラブルシューティング ワークフローの概要を説明します。 SDN の詳細については、「 ソフトウェア定義ネットワーク」を参照してください。

適用対象:Windows Server 2022、Windows Server 2019、Windows Server 2016、Azure Stack HCI、バージョン 21H2 および 20H2

エラーの種類

次の一覧は、Windows Server 2012 R2 の Hyper-V ネットワーク仮想化 (HNVv1) で市場内の運用環境のデプロイで最もよく見られる問題のクラスを表し、新しいソフトウェア定義ネットワーク (SDN) スタックとWindows Server 2016 HNVv2 で見られるのと同じ種類の問題と多くの点で一致します。

ほとんどのエラーは、クラスの小さなセットに分類できます。

  • 無効な構成またはサポートされていない構成

    ユーザーが NorthBound API を誤って呼び出すか、無効なポリシーで呼び出します。

  • ポリシー アプリケーションのエラー

    ネットワーク コントローラーからのポリシーが Hyper-V ホストに配信されなかった、遅延された、またはすべての Hyper-V ホストで最新ではない (ライブ マイグレーション後など)。

  • 構成ドリフトまたはソフトウェアのバグ

    パケットが破棄されるデータ パスの問題。

  • NIC ハードウェア/ドライバーまたはアンダーレイ ネットワーク ファブリックに関連する外部エラー

    タスク オフロードの不適切な動作 (VMQ など) またはアンダーレイ ネットワーク ファブリックの構成ミス (MTU など)

    このトラブルシューティング ガイドでは、これらの各エラー カテゴリを調べ、エラーの特定と修正に使用できるベスト プラクティスと診断ツールを推奨します。

診断ツール

これらの種類のエラーのトラブルシューティング ワークフローについて説明する前に、使用可能な診断ツールを調べてみましょう。

ネットワーク コントローラー (制御パス) 診断ツールを使用するには、まずこの機能を RSAT-NetworkController インストールしてモジュールをインポートする NetworkControllerDiagnostics 必要があります。

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

HNV 診断 (データ パス) 診断ツールを使用するには、モジュールをインポートする HNVDiagnostics 必要があります。

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

ネットワーク コントローラーの診断

これらのコマンドレットは、 ネットワーク コントローラー診断コマンドレットの TechNet に記載されています。 これらは、ネットワーク コントローラー ノード間の制御パスと、Hyper-V ホスト上で実行されているネットワーク コントローラーと NC ホスト エージェント間のネットワーク ポリシーの整合性に関する問題を特定するのに役立ちます。

コマンドレットと Get-NetworkControllerReplica コマンドレットはDebug-ServiceFabricNodeStatus、いずれかのネットワーク コントローラー ノード仮想マシンから実行する必要があります。 その他すべての NC 診断コマンドレットは、ネットワーク コントローラーへの接続を持ち、ネットワーク コントローラー管理セキュリティ グループ (Kerberos) 内にあるか、ネットワーク コントローラーを管理するための X.509 証明書にアクセスできる任意のホストから実行できます。

Hyper-V ホスト 診断

これらのコマンドレットは、 Hyper-V ネットワーク仮想化 (HNV) 診断コマンドレットの TechNet に記載されています。 これらは、テナント仮想マシン (East/West) と SLB VIP (North/South) を介したイングレス トラフィック間のデータ パスの問題を特定するのに役立ちます。

、Debug-VirtualMachineQueueOperationGet-CustomerRoute、Get-PACAMapping、 Get-VMSwitchExternalPortIdGet-ProviderAddressGet-VMNetworkAdapterPortIdTest-EncapOverheadSettings は、すべての Hyper-V ホストから実行できるローカル テストです。 他のコマンドレットは、ネットワーク コントローラーを介してデータ パス テストを呼び出すため、上記のようにネットワーク コントローラーにアクセスする必要があります。

GitHub

Microsoft/SDN GitHub Repo には、これらのインボックス コマンドレットの上に構築される多くのサンプル スクリプトとワークフローがあります。 特に、診断スクリプトは Diagnostics フォルダーにあります。 Pull Requests を送信することで、これらのスクリプトに投稿するのに役立ちます。

ワークフローとガイドのトラブルシューティング

[Hoster]システムの正常性を検証する

いくつかのネットワーク コントローラー リソースには 、Configuration State という名前の埋め込みリソースがあります。 構成状態は、ネットワーク コントローラーの構成と Hyper-V ホスト上の実際の (実行中) 状態の整合性など、システムの正常性に関する情報を提供します。

構成状態をチェックするには、ネットワーク コントローラーへの接続を持つ任意の Hyper-V ホストから次を実行します。

注:

パラメーターの NetworkController 値は、ネットワーク コントローラー用に作成された X.509 >証明書のサブジェクト名に基づいて FQDN または IP アドレスにする必要があります。

パラメーターを Credential 指定する必要があるのは、ネットワーク コントローラーが Kerberos 認証を使用している場合のみです (VMM 展開では一般的です)。 資格情報は、ネットワーク コントローラー管理セキュリティ グループに含まれるユーザーに対する資格情報である必要があります。

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

構成状態メッセージの例を次に示します。

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

注:

SLB Mux Transit VM NIC のネットワーク インターフェイス リソースがエラー状態で "仮想スイッチ - ホストがコントローラーに接続されていません" というエラーが発生するシステムにバグがあります。 VM NIC リソースの IP 構成がトランジット論理ネットワークの IP プールの IP アドレスに設定されている場合、このエラーは無視しても問題ありません。

ゲートウェイ HNV プロバイダー VM NIC のネットワーク インターフェイス リソースがエラー状態で "Virtual Switch - PortBlocked" であるシステムに 2 つ目のバグがあります。 VM NIC リソースの IP 構成が (設計上) null に設定されている場合、このエラーは無視しても問題ありません。

次の表は、観察された構成状態に基づいて実行するエラー コード、メッセージ、およびフォローアップ アクションの一覧を示しています。

コード メッセージ 操作
不明 不明なエラー
HostUnreachable ホスト マシンに到達できません ネットワーク コントローラーとホスト間の管理ネットワーク接続を確認する
PAIpAddressExhausted PA IP アドレスが使い果たされました HNV プロバイダー論理サブネットの IP プール サイズを増やす
PAMacAddressExhausted PA Mac アドレスが使い果たされました Mac プールの範囲を広げる
PAAddressConfigurationFailure PA アドレスをホストに組み込めませんでした ネットワーク コントローラーとホストの間の管理ネットワーク接続を確認します。
CertificateNotTrusted 証明書が信頼されていない ホストとの通信に使用される証明書を修正します。
CertificateNotAuthorized 証明書が承認されていない ホストとの通信に使用される証明書を修正します。
PolicyConfigurationFailureOnVfp VFP ポリシーの構成の失敗 これはランタイム エラーです。 明確な回避策はありません。 ログを収集する。
PolicyConfigurationFailure NetworkController の通信エラーやその他のエラーが原因で、ポリシーをホストにプッシュできない。 明確なアクションはありません。 これは、ネットワーク コントローラー モジュールでの目標状態処理の失敗が原因です。 ログを収集する。
HostNotConnectedToController ホストがまだネットワーク コントローラーに接続されていません ポート プロファイルがホストに適用されていないか、ホストにネットワーク コントローラーから到達できません。 HostID レジストリ キーがサーバー リソースのインスタンス ID と一致することを検証する
MultipleVfpEnabledSwitches ホストには複数の VFp 対応スイッチがあります ネットワーク コントローラー ホスト エージェントでは VFP 拡張機能が有効になっている 1 つの vSwitch のみがサポートされるため、いずれかのスイッチを削除します
PolicyConfigurationFailure 証明書エラーまたは接続エラーが原因で VmNic の VNet ポリシーをプッシュできませんでした 適切な証明書が展開されているかどうかを確認します (証明書のサブジェクト名はホストの FQDN と一致する必要があります)。 また、ネットワーク コントローラーとのホスト接続を確認します
PolicyConfigurationFailure 証明書エラーまたは接続エラーが原因で VmNic の vSwitch ポリシーをプッシュできませんでした 適切な証明書が展開されているかどうかを確認します (証明書のサブジェクト名はホストの FQDN と一致する必要があります)。 また、ネットワーク コントローラーとのホスト接続を確認します
PolicyConfigurationFailure 証明書エラーまたは接続エラーが原因で VmNic のファイアウォール ポリシーをプッシュできませんでした 適切な証明書が展開されているかどうかを確認します (証明書のサブジェクト名はホストの FQDN と一致する必要があります)。 また、ネットワーク コントローラーとのホスト接続を確認します
DistributedRouterConfigurationFailure ホスト vNic で分散ルーター設定を構成できませんでした TCPIP スタック エラー。 このエラーが報告されたサーバー上の PA と DR ホスト vNIC のクリーンアップが必要になる場合があります
DhcpAddressAllocationFailure VMNic の DHCP アドレス割り当てに失敗しました NIC リソースで静的 IP アドレス属性が構成されているかどうかを確認する
CertificateNotTrusted
CertificateNotAuthorized		 ネットワークエラーまたは証明書エラーが原因で多重化に接続できませんでした エラー メッセージ コードで提供されている数値コードを確認します。これは winsock エラー コードに対応します。 証明書エラーはきめ細かい (証明書を検証できない、証明書が承認されていないなど)
HostUnreachable MUX が異常です (一般的なケースは BGPRouter が切断されています) RRAS (BGP 仮想マシン) または Top-of-Rack (ToR) スイッチ上の BGP ピアに到達できないか、ピアリングが正常に行われません。 ソフトウェア Load Balancer マルチプレクサー リソースと BGP ピア (ToR または RRAS 仮想マシン) の両方で BGP 設定を確認する
HostNotConnectedToController SLB ホスト エージェントが接続されていません SLB ホスト エージェント サービスが実行されていることを確認します。SLBM (NC) がホスト エージェントの実行状態によって提示された証明書を拒否した場合に微妙な情報が表示される理由については、SLB ホスト エージェント ログ (自動実行) を参照してください
PortBlocked VNET/ACL ポリシーがないため、VFP ポートがブロックされます その他のエラーがあるかどうかを確認します。これにより、ポリシーが構成されていない可能性があります。
オーバー ロード Loadbalancer MUX がオーバーロードされている 多重化に関するパフォーマンスの問題
RoutePublicationFailure ロード バランス MUX が BGP ルーターに接続されていない MUX に BGP ルーターとの接続があり、BGP ピアリングが正しく設定されているかどうかを確認する
VirtualServerUnreachable ロード バランス MUX が SLB マネージャーに接続されていません SLBM と多重化の間の接続を確認する
QosConfigurationFailure QOS ポリシーの構成に失敗しました QOS 予約が使用されている場合、すべての VM で十分な帯域幅が使用可能かどうかを確認する

ネットワーク コントローラーと Hyper-V ホスト (NC ホスト エージェント サービス) 間のネットワーク接続を確認する

次のコマンドをnetstat実行して、NC ホスト エージェントとネットワーク コントローラー ノードと Hyper-V ホスト上の 1 つのソケットの間に 3 つのESTABLISHEDLISTENING接続があることを検証します。

  • Hyper-V ホスト上のポート TCP:6640 でのリッスン (NC ホスト エージェント サービス)
  • ポート 6640 の Hyper-V ホスト IP からエフェメラル ポートの NC ノード IP への 2 つの確立された接続 (> 32000)
  • 一時的なポートの Hyper-V ホスト IP からポート 6640 のネットワーク コントローラー REST IP への 1 つの確立された接続

注:

その特定のホストにテナント仮想マシンがデプロイされていない場合、Hyper-V ホストに確立された接続は 2 つだけである可能性があります。

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

ホスト エージェント サービスを確認する

ネットワーク コントローラーは、Hyper-V ホスト上の 2 つのホスト エージェント サービス (SLB ホスト エージェントと NC ホスト エージェント) と通信します。 これらのサービスの一方または両方が実行されていない可能性があります。 状態を確認し、実行されていない場合は再起動します。

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

ネットワーク コントローラーの正常性を確認する

3 つのESTABLISHED接続がない場合、またはネットワーク コントローラーが応答していないと思われる場合は、次のコマンドレットを使用して、すべてのノードとサービス モジュールが稼働していることを確認チェック。

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

ネットワーク コントローラー サービス モジュールは次のとおりです。

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

が であり ReplicaStatusReadyHealthState 、 であることを Ok確認します。

運用デプロイでは、マルチノード ネットワーク コントローラーを使用して、各サービスがプライマリになっているノードとその個々のレプリカの状態をチェックすることもできます。

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

各サービスの [レプリカの状態] が [準備完了] になっていることを確認します。

ネットワーク コントローラーと各 Hyper-V ホスト間の対応する HostID と証明書を確認する

Hyper-V ホストで、次のコマンドレットを実行して、HostID がネットワーク コントローラー上のサーバー リソースのインスタンス ID に対応することをチェックします

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

修復

SDNExpress スクリプトまたは手動デプロイを使用する場合は、サーバー リソースのインスタンス ID と一致するようにレジストリ内の HostId キーを更新します。 Hyper-V ホスト (物理サーバー) でネットワーク コントローラー ホスト エージェントを再起動します。VMM を使用している場合は、VMM から Hyper-V サーバーを削除し、HostId レジストリ キーを削除します。 次に、VMM 経由でサーバーを再度追加します。

Hyper-V ホスト (NC ホスト エージェント サービス) とネットワーク コントローラー ノード間の (SouthBound) 通信に対して、Hyper-V ホストで使用される X.509 証明書の拇印 (ホスト名は証明書のサブジェクト名になります) が同じであることを確認します。 また、ネットワーク コントローラーの REST 証明書のサブジェクト名CN=<FQDN or IP>が であることをチェックします。

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

また、各証明書の次のパラメーターをチェックして、サブジェクト名が想定される内容 (ホスト名または NC REST FQDN または IP)、証明書の有効期限がまだ切れていない、証明書チェーン内のすべての証明機関が信頼されたルート機関に含まれていることを確認することもできます。

  • 件名
  • 有効期限
  • ルート機関によって信頼される

Hyper-V ホストで複数の証明書のサブジェクト名が同じである場合、ネットワーク コントローラー ホスト エージェントは、ネットワーク コントローラーに提示する証明書をランダムに選択します。 これは、ネットワーク コントローラーに認識されているサーバー リソースの拇印と一致しない可能性があります。 この場合は、Hyper-V ホストで同じサブジェクト名の証明書のいずれかを削除し、ネットワーク コントローラー ホスト エージェント サービスを再起動します。 それでも接続できない場合は、Hyper-V ホストで同じサブジェクト名を持つ他の証明書を削除し、VMM で対応するサーバー リソースを削除します。 次に、VMM でサーバー リソースを再作成します。これにより新しい X.509 証明書が生成され、Hyper-V ホストにインストールされます。

SLB 構成の状態を確認する

SLB 構成状態は、コマンドレットへの Debug-NetworkController 出力の一部として決定できます。 このコマンドレットは、JSON ファイル内のネットワーク コントローラー リソースの現在のセット、各 Hyper-V ホスト (サーバー) からのすべての IP 構成、およびホスト エージェント データベース テーブルからのローカル ネットワーク ポリシーも出力します。

既定では、より多くのトレースが収集されます。 トレースを収集しない場合は、 パラメーターを -IncludeTraces:$false 追加します。

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

注:

既定の出力場所は <、working_directory>\NCDiagnostics\ ディレクトリです。 既定の出力ディレクトリは、 パラメーターを使用 -OutputDirectory して変更できます。

SLB 構成状態情報は、このディレクトリの 診断-slbstateResults.Json ファイルにあります。

この JSON ファイルは、次のセクションに分けることができます。

  • 生地
    • SlbmVips - このセクションでは、SLB Muxes と SLB ホスト エージェントの間で構成と正常性を調整するためにネットワーク コントローラーによって使用される SLB Manager VIP アドレスの IP アドレスを一覧表示します。
    • MuxState - このセクションでは、展開された SLB Mux ごとに 1 つの値が一覧表示され、多重化の状態が表示されます
    • ルーターの構成 - このセクションでは、アップストリーム ルーターの (BGP ピア) 自律システム番号 (ASN)、トランジット IP アドレス、ID を一覧表示します。 また、SLB 多重化 ASN とトランジット IP も一覧表示されます。
    • 接続ホスト情報 - このセクションでは、負荷分散されたワークロードを実行するために使用できるすべての Hyper-V ホストの管理 IP アドレスを一覧表示します。
    • Vip 範囲 - このセクションでは、パブリックおよびプライベート VIP IP プールの範囲を一覧表示します。 SLBM VIP は、これらの範囲のいずれかから割り当てられた IP として含まれます。
    • 多重化ルート - このセクションでは、その特定の多重化のすべてのルート アドバタイズを含む展開された SLB Mux ごとに 1 つの値を一覧表示します。
  • Tenant
    • VipConsolidatedState - このセクションでは、アドバタイズされたルート プレフィックス、Hyper-V ホスト、DIP エンドポイントなど、各テナント VIP の接続状態が一覧表示されます。

注:

SLB 状態は、Microsoft SDN GitHub リポジトリで使用できる DumpSlbRestState スクリプトを使用して直接確認できます。

ゲートウェイの検証

ネットワーク コントローラーから:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

ゲートウェイ VM から:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

ラック (ToR) スイッチの上部から:

sh ip bgp summary (for 3rd party BGP Routers)

Windows BGP ルーター:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

これらに加えて、これまでに発生した問題 (特に SDNExpress ベースのデプロイ) から、GW VM でテナント コンパートメントが構成されない最も一般的な理由は、FabricConfig.psd1 の GW 容量が TenantConfig.psd1 のネットワーク Connections (S2S トンネル) に割り当てようとする場合と比べて低いようです。 これは、次のコマンドレットの出力を比較することで簡単に確認できます。

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hoster]Data-Plane の検証

ネットワーク コントローラーがデプロイされ、テナント仮想ネットワークとサブネットが作成され、VM が仮想サブネットにアタッチされた後、ホストによって追加のファブリック レベル テストを実行してテナント接続をチェックできます。

HNV プロバイダーの論理ネットワーク接続を確認する

Hyper-V ホストで実行されている最初のゲスト VM がテナント仮想ネットワークに接続されると、ネットワーク コントローラーは Hyper-V ホストに 2 つの HNV プロバイダー IP アドレス (PA IP アドレス) を割り当てます。 これらの IP は、HNV プロバイダー論理ネットワークの IP プールから取得され、ネットワーク コントローラーによって管理されます。 これら 2 つの HNV IP アドレスを確認するには、次のようにします。

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

これらの HNV プロバイダー IP アドレス (PA IP) は、別の TCPIP ネットワーク コンパートメントで作成されたイーサネット アダプターに割り当てられ、X は HNV プロバイダー (トランスポート) 論理ネットワークに割り当てられた VLAN である VLANX のアダプター名を持ちます。

HNV プロバイダー論理ネットワークを使用する 2 つの Hyper-V ホスト間の接続は、追加コンパートメント (-c Y) パラメーターを持つ ping によって行うことができます。Y は PAhostVNIC が作成される TCPIP ネットワーク コンパートメントです。 このコンパートメントは、次のコマンドを実行して決定できます。

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

注:

PA ホスト vNIC アダプターはデータ パスでは使用されないため、"vEthernet (PAhostVNic) アダプター" に IP が割り当てられない。

たとえば、Hyper-V ホスト 1 と 2 には、次の HNV プロバイダー (PA) IP アドレスがあるとします。

Hyper-V ホスト PA IP アドレス 1 PA IP アドレス 2
ホスト 1 10.10.182.64 10.10.182.65
ホスト 2 10.10.182.66 10.10.182.67

次のコマンドを使用して 2 つの間で ping を実行して、HNV プロバイダーの論理ネットワーク接続をチェックできます。

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

修復

HNV プロバイダー ping が機能しない場合は、VLAN 構成を含む物理ネットワーク接続をチェックします。 各 Hyper-V ホスト上の物理 NIC は、特定の VLAN が割り当てられていないトランク モードである必要があります。 管理ホスト vNIC は、管理論理ネットワークの VLAN に分離する必要があります。

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

HNV プロバイダー論理ネットワークでの MTU とジャンボ フレームのサポートを確認する

HNV プロバイダー論理ネットワークのもう 1 つの一般的な問題は、物理ネットワーク ポートやイーサネット カードに VXLAN (または NVGRE) カプセル化からのオーバーヘッドを処理するのに十分な大きな MTU が構成されていないことです。

注:

一部のイーサネット カードとドライバーは、ネットワーク コントローラー ホスト エージェントによって自動的に 160 の値に設定される新しい*EncapOverheadキーワード (keyword)をサポートしています。 この値は、アドバタイズされた MTU として合計が使用される *JumboPacket キーワード (keyword)の値に追加されます。

たとえば、 *EncapOverhead = 160 と *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

HNV プロバイダー論理ネットワークで、より大きな MTU サイズのエンド ツー エンドがサポートされているかどうかをテストするには、次のコマンドレットを Test-LogicalNetworkSupportsJumboPacket 使用します。

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

修復

  • 物理スイッチ ポートの MTU サイズを 1674B 以上に調整します (14B イーサネット ヘッダーとトレーラーを含む)
  • NIC カードが EncapOverhead キーワード (keyword)をサポートしていない場合は、JumboPacket キーワード (keyword)を 1674B 以上に調整します

テナント VM NIC 接続を確認する

ゲスト VM に割り当てられた各 VM NIC には、プライベート顧客アドレス (CA) と HNV プロバイダー アドレス (PA) 領域の間に CA-PA マッピングがあります。 これらのマッピングは、各 Hyper-V ホスト上の OVSDB サーバー テーブルに保持され、次のコマンドレットを実行することで確認できます。

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

注:

予想される CA-PA マッピングが特定のテナント VM に対して出力されない場合は、コマンドレットを使用してGet-NetworkControllerNetworkInterface、ネットワーク コントローラー上の VM NIC と IP 構成リソースをチェックしてください。 また、NC ホスト エージェントとネットワーク コントローラー ノード間の確立された接続をチェックします。

この情報を使用すると、コマンドレットを使用して、ネットワーク コントローラーから Hoster によってテナント VM ping を Test-VirtualNetworkConnection 開始できるようになりました。

特定のトラブルシューティング シナリオ

次のセクションでは、特定のシナリオのトラブルシューティングに関するガイダンスを提供します。

2 つのテナント仮想マシン間にネットワーク接続がない

  1. [テナント]テナント仮想マシンの Windows ファイアウォールでトラフィックがブロックされていないことを確認します。
  2. [テナント]を実行 ipconfigして、テナント仮想マシンに IP アドレスが割り当てられていることを確認します。
  3. [Hoster]Hyper-V ホストからを実行 Test-VirtualNetworkConnection して、問題の 2 つのテナント仮想マシン間の接続を検証します。

注:

VSID は、仮想サブネット ID を参照します。 VXLAN の場合、これは VXLAN ネットワーク識別子 (VNI) です。 この値は、 コマンドレットを Get-PACAMapping 実行することで確認できます。

例

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

ホスト "sa18n30-2.sa18.nttest.microsoft.com" の SenderCA IP が 192.168.1.4 の "Green Web VM 1" の間に CA ping を作成し、Mgmt IP が 10.127.132.153 の Host "sa18n30-2.sa18.nttest.microsoft.com" を ListenerCA IP の 192.168.1.5 に両方とも仮想サブネット (VSID) 4114 にアタッチします。

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[テナント]トラフィックをブロックする仮想サブネットまたは VM ネットワーク インターフェイスに、分散ファイアウォール ポリシーが指定されていないことを確認します。

sa18.nttest.microsoft.com ドメインの sa18n30nc にあるデモ環境で見つかったネットワーク コントローラー REST API に対してクエリを実行します。

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

この ACL を参照している IP 構成と仮想サブネットを確認する

  1. [Hoster]対象の 2 つのテナント仮想マシンをホストしている両方の Hyper-V ホストでを実行Get-ProviderAddressし、Hyper-V ホストからまたは ping -c <compartment> Hyper-V ホストから実行Test-LogicalNetworkConnectionして、HNV プロバイダー論理ネットワーク上の接続を検証します
  2. [Hoster]HYPER-V ホストと、Hyper-V ホスト間のレイヤ 2 スイッチング デバイスで MTU 設定が正しいことを確認します。 対象のすべての Hyper-V ホストでを実行 Test-EncapOverheadValue します。 また、間のすべてのレイヤ 2 スイッチで MTU が 1674 バイト以上に設定され、最大 160 バイトのオーバーヘッドが考慮されることをチェックします。
  3. [Hoster]PA IP アドレスが存在しない場合や CA 接続が切断された場合は、ネットワーク ポリシーが受信されていることを確認するためにチェック。 を実行 Get-PACAMapping して、オーバーレイ仮想ネットワークの作成に必要なカプセル化規則と CA-PA マッピングが正しく確立されているかどうかを確認します。
  4. [Hoster]ネットワーク コントローラー ホスト エージェントがネットワーク コントローラーに接続されていることを確認します。 これを行うには、 を実行します netstat -anp tcp |findstr 6640。
  5. [Hoster]HKLM/ のホスト ID が、テナント仮想マシンをホストしているサーバー リソースのインスタンス ID と一致することを確認します。
  6. [Hoster]ポート プロファイル ID が、テナント仮想マシンの VM ネットワーク インターフェイスのインスタンス ID と一致することを確認します。

ログ記録、トレース、高度な診断

次のセクションでは、高度な診断、ログ記録、トレースに関する情報を提供します。

ネットワーク コントローラーの一元的なログ記録

ネットワーク コントローラーは、デバッガー ログを自動的に収集し、それらを一元的な場所に格納できます。 ネットワーク コントローラーを初めてデプロイするとき、または後でいつでも、ログ収集を有効にすることができます。 ログはネットワーク コントローラーから収集され、ネットワーク コントローラーによって管理されるネットワーク要素 (ホスト マシン、ソフトウェア ロード バランサー (SLB)、ゲートウェイ マシン) が収集されます。

これらのログには、ネットワーク コントローラー クラスター、ネットワーク コントローラー アプリケーション、ゲートウェイ ログ、SLB、仮想ネットワーク、分散ファイアウォールのデバッグ ログが含まれます。 新しいホスト/SLB/ゲートウェイがネットワーク コントローラーに追加されるたびに、それらのマシンでログ記録が開始されます。 同様に、ホスト/SLB/ゲートウェイがネットワーク コントローラーから削除されると、それらのマシンでログ記録が停止します。

ログ記録を有効にする

コマンドレットを使用してネットワーク コントローラー クラスターをインストールすると、ログ記録が自動的に Install-NetworkControllerCluster 有効になります。 既定では、ログは %systemdrive%\SDNDiagnostics のネットワーク コントローラー ノードでローカルに収集されます。 この場所は、(ローカルではなく) リモート ファイル共有に変更することをお勧めします。

ネットワーク コントローラー クラスター ログは、%programData%\Windows Fabric\log\Traces に格納されます。 ログ収集の一元化された場所は、 パラメーターを使用して DiagnosticLogLocation 指定できます。これはリモート ファイル共有でもあることをお勧めします。

この場所へのアクセスを制限する場合は、 パラメーターを使用してアクセス資格情報を LogLocationCredential 指定できます。 ログの場所にアクセスするための資格情報を指定する場合は、 パラメーターも指定 CredentialEncryptionCertificate する必要があります。これは、ネットワーク コントローラー ノードにローカルに格納されている資格情報を暗号化するために使用されます。

既定の設定では、中央の場所に少なくとも 75 GB の空き領域があり、3 ノードのネットワーク コントローラー クラスターのローカル ノード (中央の場所を使用していない場合) には 25 GB を使用することをお勧めします。

ログ記録の設定を変更する

コマンドレットを使用して、ログ記録の設定を Set-NetworkControllerDiagnostic いつでも変更できます。 次の設定を変更できます。

  • 一元化されたログの場所。

    パラメーターを使用して、すべてのログを格納する場所を DiagnosticLogLocation 変更できます。

  • ログの場所にアクセスするための資格情報。

    パラメーターを使用して、資格情報を変更してログの場所に LogLocationCredential アクセスできます。

  • ローカル ログに移動します。

    ログを格納する一元的な場所を指定した場合は、パラメーターを使用 UseLocalLogLocation してネットワーク コントローラー ノードでローカルにログ記録に戻すことができます (ディスク領域の要件が大きいため推奨されません)。

  • ログ スコープ。

    既定では、すべてのログが収集されます。 ネットワーク コントローラー クラスター ログのみを収集するようにスコープを変更できます。

  • ログ レベル。

    既定のログ レベルは Informational です。 [エラー]、[警告]、または [詳細] に変更できます。

  • ログのエージング時間。

    ログは循環形式で格納されます。 ローカル ログを使用する場合も、一元的なログ記録を使用する場合でも、既定では 3 日間のログデータがあります。 この制限時間は、 パラメーターを使用して LogTimeLimitInDays 変更できます。

  • ログ エージング サイズ。

    既定では、集中ログを使用する場合は最大 75 GB のログ データ、ローカル ログを使用する場合は 25 GB になります。 この制限は、 パラメーターで LogSizeLimitInMBs 変更できます。

ログとトレースの収集

VMM の展開では、既定でネットワーク コントローラーの一元的なログ記録が使用されます。 これらのログのファイル共有の場所は、ネットワーク コントローラー サービス テンプレートをデプロイするときに指定されます。

ファイルの場所が指定されていない場合は、 C:\Windows\tracing\SDNDiagnostics の下にログが保存された各ネットワーク コントローラー ノードでローカル ログが使用されます。 これらのログは、次の階層を使用して保存されます。

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • トレース

ネットワーク コントローラーは (Azure) Service Fabric を使用します。 特定の問題のトラブルシューティングを行うときは、Service Fabric ログが必要になる場合があります。 これらのログは、C :\ProgramData\Microsoft\Service Fabric の各ネットワーク コントローラー ノードにあります。

ユーザーがコマンドレットを Debug-NetworkController 実行した場合、ネットワーク コントローラーのサーバー リソースで指定されている各 Hyper-V ホストで、さらに多くのログを使用できるようになります。 これらのログ (およびトレースが有効な場合) は 、C:\NCDiagnostics の下に保持されます。

SLB 診断

SLBM ファブリック エラー (ホスティング サービス プロバイダー アクション)

  1. ソフトウェア Load Balancer マネージャー (SLBM) が機能していること、およびオーケストレーション レイヤーが相互に通信できることを確認します。SLBM -> SLB Mux と SLBM -> SLB ホスト エージェント。 ネットワーク コントローラー REST エンドポイントにアクセスできる任意のノードから DumpSlbRestState を実行します。
  2. いずれかのネットワーク コントローラー ノード VM (できればプライマリ ネットワーク コントローラー ノード - Get-NetworkControllerReplica) で PerfMon の SDNSLBMPerfCounters を検証します。
    1. Load Balancer (LB) エンジンは SLBM に接続されていますか? (SLBM LBEngine 構成合計 > 0)
    2. SLBM は少なくとも独自のエンドポイントについて知っていますか? (VIP エンドポイントの合計> = 2)
    3. Hyper-V (DIP) ホストは SLBM に接続されていますか? (接続されている HP クライアント == num サーバー)
    4. SLBM は多重化に接続されていますか? (Muxes Connected == Muxes Healthy on SLBM == 正常なレポートの多重化 = # SLB Muxes VM)。
  3. 設定された BGP ルータが SLB MUX と正常にピアリングされていることを確認します。
    1. リモート アクセスで RRAS を使用している場合 (つまり、BGP 仮想マシン)。
      1. Get-BgpPeer は接続済みと表示されます。
      2. Get-BgpRouteInformation は、SLBM セルフ VIP のルートを少なくとも示す必要があります。
    2. BGP ピアとして物理 Top-of-Rack (ToR) スイッチを使用する場合は、ドキュメントを参照してください。
      1. 例: # show bgp instance
  4. SLB 多重化 VM 上の PerfMon の SlbMuxPerfCounters カウンターと SLBMUX カウンターを検証します。
  5. ソフトウェア Load Balancer Manager リソースで構成状態と VIP 範囲を確認します。
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8(チェック IP プールの VIP 範囲と SLBM セルフ VIP (LoadBalanacerManagerIPAddress) とテナントに接続するすべての VIP がこれらの範囲内にあることを確認します)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

上記のいずれかのチェックが失敗した場合、テナント SLB 状態もエラー モードになります。

修復

表示される次の診断情報に基づいて、次の問題を修正します。

  • SLB マルチプレクサが接続されていることを確認する
    • 証明書の問題を修正する
    • ネットワーク接続の問題を修正する
  • BGP ピアリング情報が正常に構成されていることを確認する
  • レジストリのホスト ID がサーバー リソースのサーバー インスタンス ID と一致していることを確認します ( HostNotConnected エラー コードの付録を参照してください)
  • ログを収集する

SLBM テナント エラー (ホスティング サービス プロバイダーとテナント アクション)

  1. [Hoster]LoadBalancer リソースがエラー状態であるかどうかを確認 Debug-NetworkControllerConfigurationState します。 付録のアクション項目テーブルに従って軽減してみてください。
    1. VIP エンドポイントが存在し、ルートをアドバタイズしていることを確認します。
    2. VIP エンドポイントで検出された DIP エンドポイントの数を確認します。
  2. [テナント]リソースLoad Balancer正しく指定されていることを検証します。
    1. SLBM に登録されている DIP エンドポイントが、LoadBalancer バックエンド アドレス プール IP 構成に対応するテナント仮想マシンをホストしていることを検証します。
  3. [Hoster]DIP エンドポイントが検出または接続されていない場合:

    1. チェック Debug-NetworkControllerConfigurationState

      NC および SLB ホスト エージェントが を使用して netstat -anp tcp |findstr 6640)ネットワーク コントローラー イベント コーディネーターに正常に接続されていることを検証します。

    2. nchostagentチェックイン HostIdサービス レジストリ (付録の参照HostNotConnectedエラー コード) は、対応するサーバー リソースのインスタンス ID (Get-NCServer |convertto-json -depth 8) と一致します。

    3. 仮想マシン ポートのポート プロファイル ID が、対応する仮想マシン NIC リソースのインスタンス ID と一致するかどうかを確認します。

  4. [ホスティング プロバイダー]ログを収集します。

SLB 多重化トレース

ソフトウェアLoad Balancerマルチプレクサからの情報は、イベント ビューアーを介して決定することもできます。

  1. [イベント ビューアー表示] メニューの [分析ログとデバッグ ログの表示] を選択します。
  2. イベント ビューアーの [アプリケーションとサービス ログ>] [Microsoft>Windows>SlbMuxDriver>トレース] に移動します。
  3. それを右クリックし、[ ログの有効化] を選択します。

注:

問題を再現しようとしている間は、このログ記録を短時間だけ有効にすることをお勧めします。

VFP と vSwitch のトレース

テナント仮想ネットワークに接続されているゲスト VM をホストしている Hyper-V ホストから、VFP トレースを収集して、問題が発生する可能性がある場所を特定できます。

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes