Dela via

Felsöka den programvarudefinierade nätverksstacken för Windows Server

  • Artikel

Den här guiden undersöker vanliga SDN-fel (Software Defined Networking) och felscenarier och beskriver ett felsökningsarbetsflöde som använder tillgängliga diagnostikverktyg. Mer information om SDN finns i Programvarudefinierade nätverk.

Gäller för: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, version 21H2 och 20H2

Feltyper

Följande lista representerar den klass av problem som oftast visas med Hyper-V Network Virtualization (HNVv1) i Windows Server 2012 R2 från produktionsdistributioner på marknaden och sammanfaller på många sätt med samma typer av problem som visas i Windows Server 2016 HNVv2 med den nya SDN-stacken (Software Defined Network).

De flesta fel kan klassificeras i en liten uppsättning klasser:

  • Ogiltig konfiguration eller konfiguration som inte stöds

    En användare anropar NorthBound-API:et felaktigt eller med en ogiltig princip.

  • Fel i principprogrammet

    Principen från nätverksstyrenheten levererades inte till en Hyper-V-värd, fördröjd eller inte uppdaterad på alla Hyper-V-värdar (till exempel efter en direktmigrering).

  • Konfigurationsavvikelse eller programfel

    Problem med datasökväg som resulterar i borttagna paket.

  • Externt fel som rör NIC-maskinvara/drivrutiner eller underläggsnätverksinfrastrukturen

    Felaktig uppgiftsavlastning (till exempel VMQ) eller felkonfigurerad underläggsnätverksinfrastruktur (till exempel MTU)

    Den här felsökningsguiden undersöker var och en av dessa felkategorier och rekommenderar metodtips och diagnostikverktyg som är tillgängliga för att identifiera och åtgärda felet.

Diagnostikverktyg

Innan vi diskuterar felsökningsarbetsflödena för var och en av dessa typer av fel ska vi undersöka de tillgängliga diagnostikverktygen.

Om du vill använda diagnostikverktygen för nätverksstyrenheten (kontrollsökväg) måste du först installera RSAT-NetworkController funktionen och importera modulen NetworkControllerDiagnostics :

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

Om du vill använda diagnostikverktygen för HNV-diagnostik (datasökväg) måste du importera modulen HNVDiagnostics :

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

Diagnostik för nätverksstyrenhet

Dessa cmdletar dokumenteras på TechNet i cmdleten Diagnostik för nätverksstyrenhet. De hjälper till att identifiera problem med nätverksprincipkonsekvens i kontrollsökvägen mellan nätverksstyrenhetsnoder och mellan nätverksstyrenheten och NC-värdagenterna som körs på Hyper-V-värdarna.

Debug-ServiceFabricNodeStatus Cmdletarna och Get-NetworkControllerReplica måste köras från en av de virtuella datorerna för nätverksstyrenhetens nod. Alla andra NC Diagnostic-cmdletar kan köras från valfri värd, som har anslutning till nätverksstyrenheten och finns i antingen säkerhetsgruppen För hantering av nätverksstyrenhet (Kerberos) eller har åtkomst till X.509-certifikatet för hantering av nätverksstyrenheten.

Diagnostik för Hyper-V-värd

Dessa cmdletar dokumenteras på TechNet i cmdleten Hyper-V-nätverksvirtualisering (HNV). De hjälper dig att identifiera problem i datasökvägen mellan virtuella klientdatorer (öst/väst) och inkommande trafik via en SLB VIP (nord/syd).

, Debug-VirtualMachineQueueOperation, , , , , Get-VMSwitchExternalPortIdoch Test-EncapOverheadSettings är alla lokala tester som kan köras från valfri Hyper-V-värd. Get-VMNetworkAdapterPortIdGet-ProviderAddressGet-PACAMappingGet-CustomerRoute De andra cmdletarna anropar datasökvägstester via nätverksstyrenheten och behöver därför åtkomst till nätverksstyrenheten enligt beskrivningen ovan.

GitHub

Microsoft/SDN GitHub-lagringsplatsen har många exempelskript och arbetsflöden som bygger på dessa in-box-cmdletar. I synnerhet finns diagnostikskript i mappen Diagnostik . Hjälp oss att bidra till dessa skript genom att skicka pull-begäranden.

Felsöka arbetsflöden och guider

[Värd] Verifiera systemets hälsa

Det finns en inbäddad resurs med namnet Configuration State i flera av nätverksstyrenhetsresurserna. Konfigurationstillståndet innehåller information om systemets hälsotillstånd, inklusive konsekvensen mellan nätverksstyrenhetens konfiguration och det faktiska tillståndet (körs) på Hyper-V-värdarna.

Kontrollera konfigurationstillståndet genom att köra följande från valfri Hyper-V-värd med anslutning till nätverksstyrenheten.

Kommentar

Värdet för parametern NetworkController ska antingen vara FQDN- eller IP-adressen baserat på ämnesnamnet för X.509-certifikatet >som skapats för nätverksstyrenheten.

Parametern Credential behöver bara anges om nätverksstyrenheten använder Kerberos-autentisering (vanligtvis i VMM-distributioner). Autentiseringsuppgifterna måste vara för en användare som finns i säkerhetsgruppen för nätverksstyrenhetshantering.

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

Ett exempel på ett meddelande om konfigurationstillstånd visas nedan:

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.
----------------------------------------------------------------------------------------------------------

Kommentar

Det finns en bugg i systemet där nätverksgränssnittsresurserna för SLB Mux Transit VM NIC är i ett feltillstånd med felet "Virtuell växel – Värden är inte ansluten till styrenheten". Det här felet kan ignoreras på ett säkert sätt om IP-konfigurationen i VM NIC-resursen är inställd på en IP-adress från det logiska överföringsnätverkets IP-pool.

Det finns en andra bugg i systemet där nätverksgränssnittsresurserna för gateway-HNV-providerns virtuella nätverkskort är i ett feltillstånd med felet "Virtuell växel – PortBlocked". Det här felet kan också ignoreras på ett säkert sätt om IP-konfigurationen i VM NIC-resursen är inställd på null (avsiktligt).

Tabellen nedan visar listan över felkoder, meddelanden och uppföljningsåtgärder som ska utföras baserat på det konfigurationstillstånd som observerats.

Kod Meddelande Åtgärd
Okänt Okänt fel
HostUnreachable Värddatorn kan inte nås Kontrollera nätverksanslutningen för hantering mellan nätverksstyrenhet och värd
PAIpAddressExhausted PA IP-adresserna är uttömda Öka HNV-providerns logiska undernäts IP-poolstorlek
PAMacAddressExhausted PA Mac-adresserna är uttömda Öka Mac-poolintervallet
PAAddressConfigurationFailure Det gick inte att fylla i PA-adresser till värden Kontrollera nätverksanslutningen för hantering mellan nätverksstyrenheten och värden.
CertificateNotTrusted Certifikatet är inte betrott Åtgärda de certifikat som används för kommunikation med värden.
CertificateNotAuthorized Certifikatet är inte auktoriserat Åtgärda de certifikat som används för kommunikation med värden.
PolicyConfigurationFailureOnVfp Det gick inte att konfigurera VFP-principer Det här är ett körningsfel. Inga definitiva lösningar. Samla in loggar.
PolicyConfigurationFailure Det gick inte att push-överföra principer till värdarna på grund av kommunikationsfel eller andra fel i NetworkController. Inga konkreta åtgärder. Detta beror på fel i måltillståndsbearbetningen i nätverksstyrenhetsmodulerna. Samla in loggar.
HostNotConnectedToController Värden är ännu inte ansluten till nätverksstyrenheten Portprofilen tillämpas inte på värden eller så kan värden inte nås från nätverksstyrenheten. Verifiera att HostID-registernyckeln matchar instans-ID:t för serverresursen
MultipleVfpEnabledSwitches Det finns flera VFp-aktiverade växlar på värden Ta bort en av växlarna eftersom värdagenten för nätverksstyrenheten endast stöder en vSwitch med VFP-tillägget aktiverat
PolicyConfigurationFailure Det gick inte att push-överföra VNet-principer för ett VmNic på grund av certifikatfel eller anslutningsfel Kontrollera om rätt certifikat har distribuerats (certifikatmottagarens namn måste matcha värdens FQDN). Kontrollera även värdanslutningen med nätverksstyrenheten
PolicyConfigurationFailure Det gick inte att push-överföra vSwitch-principer för ett VmNic på grund av certifikatfel eller anslutningsfel Kontrollera om rätt certifikat har distribuerats (certifikatmottagarens namn måste matcha värdens FQDN). Kontrollera även värdanslutningen med nätverksstyrenheten
PolicyConfigurationFailure Det gick inte att skicka brandväggsprinciper för ett VmNic på grund av certifikatfel eller anslutningsfel Kontrollera om rätt certifikat har distribuerats (certifikatmottagarens namn måste matcha värdens FQDN). Kontrollera även värdanslutningen med nätverksstyrenheten
DistributedRouterConfigurationFailure Det gick inte att konfigurera inställningarna för distribuerad router på värd-vNic TCPIP-stackfel. Kan kräva att pa- och DR Host vNICs rensas på servern där felet rapporterades
DhcpAddressAllocationFailure DHCP-adressallokering misslyckades för ett VMNic Kontrollera om attributet för statisk IP-adress har konfigurerats för nätverkskortsresursen
CertificateNotTrusted
CertificateNotAuthorized		 Det gick inte att ansluta till Mux på grund av nätverks- eller certifikatfel Kontrollera den numeriska koden i felmeddelandekoden: detta motsvarar winsock-felkoden. Certifikatfel är detaljerade (till exempel certifikatet kan inte verifieras, certifikatet är inte auktoriserat osv.)
HostUnreachable MUX är inte felfri (vanligt fall är BGPRouter frånkopplat) BGP-peer på växeln RRAS (BGP virtual machine) eller Top-of-Rack (ToR) kan inte nås eller inte peering. Kontrollera BGP-inställningarna för både Software Load Balancer Multiplexer-resursen och BGP-peer (virtuell ToR- eller RRAS-dator)
HostNotConnectedToController SLB-värdagenten är inte ansluten Kontrollera att SLB-värdagenttjänsten körs. Se SLB-värdagentloggar (automatisk körning) av orsaker till varför, om SLBM (NC) avvisade certifikatet som presenteras av värdagentens körningstillstånd, visar nyanserad information
PortBlocked VFP-porten blockeras på grund av brist på VNET/ACL-principer Kontrollera om det finns andra fel, vilket kan leda till att principerna inte har konfigurerats.
Överbelastad Loadbalancer MUX är överbelastad Prestandaproblem med MUX
RoutePublicationFailure Loadbalancer MUX är inte ansluten till en BGP-router Kontrollera om MUX har anslutning till BGP-routrarna och att BGP-peering är korrekt konfigurerat
VirtualServerUnreachable Loadbalancer MUX är inte ansluten till SLB Manager Kontrollera anslutningen mellan SLBM och MUX
QosConfigurationFailure Det gick inte att konfigurera QOS-principer Se om det finns tillräckligt med bandbredd för alla virtuella datorer om QOS-reservation används

Kontrollera nätverksanslutningen mellan nätverksstyrenheten och Hyper-V-värden (NC-värdagenttjänsten)

netstat Kör kommandot nedan för att verifiera att det finns tre ESTABLISHED anslutningar mellan NC-värdagenten och nätverksstyrenhetsnoderna och en LISTENING socket på Hyper-V-värden.

  • LYSSNA på port-TCP:6640 på Hyper-V-värd (NC-värdagenttjänst)
  • Två etablerade anslutningar från Hyper-V-värd-IP på port 6640 till NC-nod-IP på tillfälliga portar (> 32000)
  • En upprättad anslutning från Hyper-V-värd-IP-adressen på den tillfälliga porten till nätverksstyrenhetens REST IP på port 6640

Kommentar

Det kan bara finnas två etablerade anslutningar på en Hyper-V-värd om det inte finns några virtuella klientdatorer som distribuerats på den aktuella värden.

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

Kontrollera värdagenttjänster

Nätverksstyrenheten kommunicerar med två värdagenttjänster på Hyper-V-värdarna: SLB-värdagenten och NC-värdagenten. Det är möjligt att en eller båda tjänsterna inte körs. Kontrollera deras tillstånd och starta om om de inte körs.

Get-Service SlbHostAgent
Get-Service NcHostAgent

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

Kontrollera nätverksstyrenhetens hälsa

Om det inte finns tre ESTABLISHED anslutningar eller om nätverksstyrenheten inte svarar kontrollerar du att alla noder och tjänstmoduler är igång med hjälp av följande cmdletar.

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

Nätverksstyrenhetstjänstmodulerna är:

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

Kontrollera att ReplicaStatus är Ready och HealthState är Ok.

I en produktionsdistribution är med en nätverksstyrenhet med flera noder kan du också kontrollera vilken nod varje tjänst är primär på och dess enskilda replikstatus.

Get-NetworkControllerReplica

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

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

Kontrollera att replikstatusen är klar för varje tjänst.

Sök efter motsvarande Värd-ID:n och certifikat mellan nätverksstyrenheten och varje Hyper-V-värd

På en Hyper-V-värd kör du följande cmdletar för att kontrollera att HostID motsvarar instans-ID:t för en serverresurs på nätverksstyrenheten

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

Reparation

Om du använder SDNExpress-skript eller manuell distribution uppdaterar du HostId-nyckeln i registret så att den matchar serverresursens instans-ID. Starta om värdagenten för nätverksstyrenheten på Hyper-V-värden (fysisk server) Om du använder VMM tar du bort Hyper-V-servern från VMM och tar bort HostId-registernyckeln. Lägg sedan till servern via VMM igen.

Kontrollera att tumavtrycken för X.509-certifikaten som används av Hyper-V-värden (värdnamnet är certifikatets ämnesnamn) för (SouthBound) kommunikation mellan Hyper-V-värden (NC-värdagenttjänsten) och nätverksstyrenhetsnoderna är desamma. Kontrollera också att nätverksstyrenhetens REST-certifikat har ämnesnamnet 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**
...

Du kan också kontrollera följande parametrar för varje certifikat för att kontrollera att ämnesnamnet är vad som förväntas (värdnamn eller NC REST FQDN eller IP), certifikatet har ännu inte upphört att gälla och att alla certifikatutfärdare i certifikatkedjan ingår i den betrodda rotutfärdaren.

  • Ämnesnamn
  • Utgångsdatum
  • Betrodd av rotutfärdare

Om flera certifikat har samma ämnesnamn på Hyper-V-värden väljer nätverksstyrenhetens värdagent slumpmässigt en som ska presenteras för nätverksstyrenheten. Detta kanske inte matchar tumavtrycket för serverresursen som är känd för nätverksstyrenheten. I det här fallet tar du bort ett av certifikaten med samma ämnesnamn på Hyper-V-värden och startar sedan om värdagenttjänsten för nätverksstyrenheten. Om det fortfarande inte går att upprätta en anslutning tar du bort det andra certifikatet med samma ämnesnamn på Hyper-V-värden och tar bort motsvarande serverresurs i VMM. Återskapa sedan serverresursen i VMM, som genererar ett nytt X.509-certifikat och installerar den på Hyper-V-värden.

Kontrollera SLB-konfigurationstillståndet

SLB-konfigurationstillståndet kan fastställas som en del av utdata till cmdleten Debug-NetworkController . Den här cmdleten matar också ut den aktuella uppsättningen nätverksstyrenhetsresurser i JSON-filer, alla IP-konfigurationer från varje Hyper-V-värd (server) och en lokal nätverksprincip från värdagentdatabastabeller.

Fler spårningar samlas in som standard. Om du inte vill samla in spårningar lägger du till parametern -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

Kommentar

Standardutdataplatsen är <katalogen working_directory>\NCDiagnostics\. Standardutdatakatalogen kan ändras med hjälp av parametern -OutputDirectory .

Informationen om SLB-konfigurationstillstånd finns i filen diagnostics-slbstateResults.Json i den här katalogen.

Den här JSON-filen kan delas upp i följande avsnitt:

  • Väv
    • SlbmVips – Det här avsnittet visar IP-adressen för SLB Manager VIP-adressen, som används av nätverksstyrenheten för att samordna konfiguration och hälsa mellan SLB Muxes och SLB-värdagenter.
    • MuxState – I det här avsnittet visas ett värde för varje SLB Mux som distribueras, vilket ger tillståndet för mux
    • Routerkonfiguration – Det här avsnittet visar den överordnade routerns (BGP Peer) autonoma systemnummer (ASN), överförings-IP-adress och ID. Den kommer också att lista SLB Muxes ASN och Transit IP.
    • Ansluten värdinformation – I det här avsnittet visas hanterings-IP-adressen för alla Hyper-V-värdar som är tillgängliga för körning av belastningsutjämningsarbetsbelastningar.
    • VIP-intervall – Det här avsnittet visar en lista över de offentliga och privata IP-poolintervallen för VIP. SLBM VIP inkluderas som en allokerad IP-adress från något av dessa intervall.
    • Mux-vägar – Det här avsnittet visar ett värde för varje SLB Mux som distribueras som innehåller alla routningsannonser för just den muxen.
  • Hyresgäst
    • VipConsolidatedState – I det här avsnittet visas anslutningstillståndet för varje KLIENT-VIP, inklusive annonserade routningsprefix, Hyper-V-värd och DIP-slutpunkter.

Kommentar

SLB-tillstånd kan fastställas direkt med hjälp av DumpSlbRestState-skriptet som är tillgängligt på Microsoft SDN GitHub-lagringsplatsen.

Gatewayverifiering

Från nätverksstyrenheten:

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

Från den virtuella gatewaydatorn:

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

Uppifrån rackväxeln (ToR):

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

Windows BGP-router:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Förutom dessa, från de problem som vi har sett hittills (särskilt på SDNExpress-baserade distributioner), verkar den vanligaste orsaken till att klientfacket inte konfigureras på gw-virtuella datorer vara det faktum att GW-kapaciteten i FabricConfig.psd1 är mindre jämfört med vad folk försöker tilldela till nätverksanslutningarna (S2S-tunnlar) i TenantConfig.psd1. Detta kan kontrolleras enkelt genom att jämföra utdata från följande cmdletar:

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

[Värd] Verifiera dataplan

När nätverksstyrenheten har distribuerats har virtuella klientnätverk och undernät skapats och virtuella datorer har kopplats till de virtuella undernäten. Ytterligare tester på infrastrukturnivå kan utföras av värden för att kontrollera klientanslutningen.

Kontrollera HNV-providerns logiska nätverksanslutning

När den första virtuella gästdatorn som körs på en Hyper-V-värd har anslutits till ett virtuellt klientnätverk tilldelar nätverksstyrenheten två HNV-providerns IP-adresser (PA IP-adresser) till Hyper-V-värden. Dessa IP-adresser kommer från det logiska HNV-providernätverkets IP-pool och hanteras av nätverksstyrenheten. Så här tar du reda på vad dessa två HNV IP-adresser är:

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

Dessa IP-adresser för HNV-provider (PA IP) tilldelas till Ethernet-kort som skapats i ett separat TCPIP-nätverksfack och har ett nätverksnamn för VLANX där X är det VLAN som tilldelats det logiska HNV-providernätverket (transport).

Anslutningen mellan två Hyper-V-värdar som använder det logiska HNV-providernätverket kan utföras med en ping med ytterligare en fackparameter (-c Y) där Y är TCPIP-nätverksfacket där PAhostVNICs skapas. Det här facket kan fastställas genom att köra:

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> ...

Kommentar

Pa-värdens virtuella nätverkskort används inte i datasökvägen och har därför inte någon IP-adress tilldelad till kortet "vEthernet (PAhostVNic).

Anta till exempel att Hyper-V-värdar 1 och 2 har IP-adresser för HNV-provider (PA) för:

Hyper-V-värd PA IP-adress 1 PA IP-adress 2
Värd 1 10.10.182.64 10.10.182.65
Värd 2 10.10.182.66 10.10.182.67

vi kan pinga mellan de två med hjälp av följande kommando för att kontrollera HNV-providerns logiska nätverksanslutning.

# 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

Reparation

Om ping för HNV-providern inte fungerar kontrollerar du din fysiska nätverksanslutning, inklusive VLAN-konfiguration. De fysiska nätverkskorten på varje Hyper-V-värd ska vara i trunkläge utan någon specifik VLAN tilldelad. Det virtuella nätverkskortet för hanteringsvärden ska isoleras till det logiska hanteringsnätverkets 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> ...

Kontrollera stöd för MTU och jumboramar i HNV-providerns logiska nätverk

Ett annat vanligt problem i det logiska HNV-providernätverket är att de fysiska nätverksportarna och/eller Ethernet-kortet inte har en tillräckligt stor MTU konfigurerad för att hantera omkostnaderna från VXLAN-inkapslingen (eller NVGRE).

Kommentar

Vissa Ethernet-kort och drivrutiner stöder det nya *EncapOverhead nyckelordet som automatiskt anges av nätverksstyrenhetens värdagent till värdet 160. Det här värdet läggs sedan till i värdet för nyckelordet *JumboPacket vars sammanfattning används som den annonserade MTU:en.

Till exempel *EncapOverhead = 160 och *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

Om du vill testa om det logiska HNV-providernätverket stöder den större MTU-storleken från slutpunkt till slutpunkt använder du cmdleten 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.

Reparation

  • Justera MTU-storleken på de fysiska växelportarna till minst 1674B (inklusive 14B Ethernet-huvud och släpvagn)
  • Om ditt NIC-kort inte stöder nyckelordet EncapOverhead justerar du nyckelordet JumboPacket till minst 1674B

Kontrollera NIC-anslutningen för den virtuella klientdatorn

Varje vm-nätverkskort som tilldelats en virtuell gästdator har en CA-PA-mappning mellan den privata kundadressen (CA) och HNV-providerns adressutrymme (PA). Dessa mappningar sparas i OVSDB-servertabellerna på varje Hyper-V-värd och kan hittas genom att köra följande cmdlet.

# 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

Kommentar

Om ca-PA-mappningarna som du förväntar dig inte är utdata för en viss virtuell klientdator kontrollerar du vm-nätverkskortet och IP-konfigurationsresurserna på nätverksstyrenheten med hjälp av cmdleten Get-NetworkControllerNetworkInterface . Kontrollera också de etablerade anslutningarna mellan NOD:n för NC-värdagenten och nätverksstyrenheten.

Med den här informationen kan en ping för den virtuella klientdatorn nu initieras av värden från nätverksstyrenheten med hjälp av cmdleten Test-VirtualNetworkConnection .

Specifika felsökningsscenarier

Följande avsnitt innehåller vägledning för felsökning av specifika scenarier.

Ingen nätverksanslutning mellan två virtuella klientdatorer

  1. [Klient] Kontrollera att Windows-brandväggen på virtuella klientdatorer inte blockerar trafik.
  2. [Klient] Kontrollera att IP-adresser har tilldelats till den virtuella klientdatorn genom att köra ipconfig.
  3. [Värd] Kör Test-VirtualNetworkConnection från Hyper-V-värden för att verifiera anslutningen mellan de två virtuella klientdatorerna i fråga.

Kommentar

VSID refererar till det virtuella undernätets ID. När det gäller VXLAN är detta VXLAN Network Identifier (VNI). Du hittar det här värdet genom att köra cmdleten Get-PACAMapping .

Exempel

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

Skapa CA-ping mellan "Green Web VM 1" med SenderCA IP på 192.168.1.4 på värden "sa18n30-2.sa18.nttest.microsoft.com" med Mgmt IP på 10.127.132.153 till ListenerCA IP på 192.168.1.5 båda kopplade till virtuellt undernät (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> ...

[Klient] Kontrollera att det inte finns några distribuerade brandväggsprinciper angivna i det virtuella undernätet eller virtuella datornätverksgränssnitt som blockerar trafiken.

Fråga rest-API:et för nätverksstyrenheten som finns i demomiljön på sa18n30nc i sa18.nttest.microsoft.com-domänen.

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

Titta på IP-konfiguration och virtuella undernät som refererar till den här ACL:en

  1. [Värd] Kör Get-ProviderAddress på båda Hyper-V-värdarna som är värdar för de två virtuella klientdatorerna i fråga och kör Test-LogicalNetworkConnection sedan eller ping -c <compartment> från Hyper-V-värden för att verifiera anslutningen i det logiska HNV-providernätverket
  2. [Värd] Kontrollera att MTU-inställningarna är korrekta på Hyper-V-värdarna och alla Layer-2-växlingsenheter mellan Hyper-V-värdarna. Kör Test-EncapOverheadValue på alla Hyper-V-värdar i fråga. Kontrollera också att alla Layer-2-växlar däremellan har MTU inställt på minst 1 674 byte för att ta hänsyn till maximala omkostnader på 160 byte.
  3. [Värd] Om PA IP-adresser inte finns och/eller CA-anslutningen är bruten kontrollerar du att nätverksprincipen har tagits emot. Kör Get-PACAMapping för att se om inkapslingsreglerna och CA-PA-mappningarna som krävs för att skapa virtuella överläggsnätverk är korrekt etablerade.
  4. [Värd] Kontrollera att nätverksstyrenhetens värdagent är ansluten till nätverksstyrenheten. Gör detta genom att köra netstat -anp tcp |findstr 6640.
  5. [Värd] Kontrollera att värd-ID:t i HKLM/ matchar instans-ID:t för de serverresurser som är värdar för de virtuella klientdatorerna.
  6. [Värd] Kontrollera att portprofil-ID:t matchar instans-ID:t för de virtuella datornätverksgränssnitten för de virtuella klientdatorerna.

Loggning, spårning och avancerad diagnostik

Följande avsnitt innehåller information om avancerad diagnostik, loggning och spårning.

Centraliserad loggning av nätverksstyrenhet

Nätverksstyrenheten kan automatiskt samla in felsökningsloggar och lagra dem på en central plats. Logginsamling kan aktiveras när du distribuerar nätverksstyrenheten för första gången eller när som helst senare. Loggarna samlas in från nätverksstyrenheten och nätverkselement som hanteras av nätverksstyrenheten: värddatorer, programvarulastbalanserare (SLB) och gatewaydatorer.

Dessa loggar omfattar felsökningsloggar för nätverksstyrenhetsklustret, programmet Nätverksstyrenhet, gatewayloggar, SLB, virtuella nätverk och den distribuerade brandväggen. När en ny värd/SLB/gateway läggs till i nätverksstyrenheten startas loggningen på dessa datorer. På samma sätt stoppas loggning på dessa datorer när en värd/SLB/gateway tas bort från nätverksstyrenheten.

Aktivera loggning

Loggning aktiveras automatiskt när du installerar nätverksstyrenhetsklustret med hjälp av cmdleten Install-NetworkControllerCluster . Som standard samlas loggarna in lokalt på noderna för nätverksstyrenheten på %systemdrive%\SDNDiagnostics. Vi rekommenderar att du ändrar den här platsen till en fjärrfilresurs (inte lokal).

Klusterloggarna för nätverksstyrenheten lagras på %programData%\Windows Fabric\log\Traces. Du kan ange en central plats för loggsamling med parametern DiagnosticLogLocation med rekommendationen att detta även är en fjärrfilresurs.

Om du vill begränsa åtkomsten till den här platsen kan du ange autentiseringsuppgifterna för åtkomst med parametern LogLocationCredential . Om du anger autentiseringsuppgifterna för att komma åt loggplatsen bör du även ange parametern CredentialEncryptionCertificate som används för att kryptera autentiseringsuppgifterna som lagras lokalt på noderna för nätverksstyrenheten.

Med standardinställningarna rekommenderar vi att du har minst 75 GB ledigt utrymme på den centrala platsen och 25 GB på de lokala noderna (om du inte använder en central plats) för ett nätverksstyrenhetskluster med tre noder.

Ändra loggningsinställningar

Du kan när som helst ändra loggningsinställningarna med hjälp av cmdleten Set-NetworkControllerDiagnostic . Följande inställningar kan ändras:

  • Centraliserad loggplats.

    Du kan ändra platsen för att lagra alla loggar med parametern DiagnosticLogLocation .

  • Autentiseringsuppgifter för att komma åt loggplatsen.

    Du kan ändra autentiseringsuppgifterna för att komma åt loggplatsen med parametern LogLocationCredential .

  • Flytta till lokal loggning.

    Om du har angett central plats för att lagra loggar kan du gå tillbaka till loggning lokalt på noderna för nätverksstyrenheten med parametern UseLocalLogLocation (rekommenderas inte på grund av stora diskutrymmeskrav).

  • Loggningsomfång.

    Som standard samlas alla loggar in. Du kan ändra omfånget så att endast nätverksstyrenhetsklusterloggar samlas in.

  • Loggningsnivå.

    Standardloggningsnivån är Informational. Du kan ändra den till Fel, Varning eller Utförlig.

  • Loggens åldrandetid.

    Loggarna lagras på ett cirkulärt sätt. Du har tre dagars loggningsdata som standard, oavsett om du använder lokal loggning eller centraliserad loggning. Du kan ändra den här tidsgränsen med parametern LogTimeLimitInDays .

  • Storlek på loggens åldrande.

    Som standard har du högst 75 GB loggningsdata om du använder centraliserad loggning och 25 GB om du använder lokal loggning. Du kan ändra den här gränsen med parametern LogSizeLimitInMBs .

Samla in loggar och spårningar

VMM-distributioner använder centraliserad loggning för nätverksstyrenheten som standard. Filresursplatsen för dessa loggar anges när du distribuerar tjänstmallen Nätverksstyrenhet.

Om ingen filplats har angetts används lokal loggning på varje nätverksstyrenhetsnod med loggar som sparats under C:\Windows\tracing\SDNDiagnostics. Dessa loggar sparas med hjälp av följande hierarki:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Spårningar

Nätverksstyrenheten använder (Azure) Service Fabric. Service Fabric-loggar kan krävas vid felsökning av vissa problem. Dessa loggar finns på varje nod för nätverksstyrenheten i C:\ProgramData\Microsoft\Service Fabric.

Om en användare har kört cmdleten Debug-NetworkController blir fler loggar tillgängliga på varje Hyper-V-värd, som har angetts med en serverresurs i nätverksstyrenheten. Dessa loggar (och spårningar om de är aktiverade) sparas under C:\NCDiagnostics.

SLB-diagnostik

SLBM-infrastrukturfel (värdtjänstleverantörsåtgärder)

  1. Kontrollera att Software Load Balancer Manager (SLBM) fungerar och att orkestreringsskikten kan kommunicera med varandra: SLBM –> SLB Mux och SLBM –> SLB-värdagenter. Kör DumpSlbRestState från valfri nod med åtkomst till REST-slutpunkten för nätverksstyrenheten.
  2. Verifiera SDNSLBMPerfCounters i PerfMon på en av de virtuella datorerna för nätverksstyrenhetsnoden (helst den primära noden för nätverksstyrenheten – Get-NetworkControllerReplica):
    1. Är Load Balancer-motorn (LB) ansluten till SLBM? (SLBM LBEngine-konfigurationer Totalt > 0)
    2. Känner SLBM åtminstone till sina egna slutpunkter? (TOTALT ANTAL> VIP-slutpunkter= 2)
    3. Är Hyper-V-värdar (DIP) anslutna till SLBM? (HP-klienter anslutna == num-servrar)
    4. Är SLBM anslutet till Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Kontrollera att den konfigurerade BGP-routern är peering med SLB MUX.
    1. Om du använder RRAS med fjärråtkomst (d.v.s. virtuell BGP-dator):
      1. Get-BgpPeer ska visa ansluten.
      2. Get-BgpRouteInformation bör visa minst en väg för SLBM själv VIP.
    2. Om du använder den fysiska ToR-växeln (Top-of-Rack) som BGP-peer läser du dokumentationen:
      1. Till exempel: # show bgp instance
  4. Verifiera räknare för SlbMuxPerfCounters och SLBMUX i PerfMon på den virtuella SLB Mux-datorn.
  5. Kontrollera konfigurationstillstånd och VIP-intervall i Software Load Balancer Manager-resursen.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (Kontrollera VIP-intervall i IP-pooler och se till att SLBM self-VIP (LoadBalanacerManagerIPAddress) och eventuella klientriktade VIP:er finns inom dessa intervall)
      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 -

Om någon av kontrollerna ovan misslyckas är klientorganisationens SLB-tillstånd också i felläge.

Reparation

Åtgärda följande baserat på följande diagnostikinformation:

  • Kontrollera att SLB Multiplexers är anslutna
    • Åtgärda certifikatproblem
    • Åtgärda problem med nätverksanslutning
  • Kontrollera att BGP-peeringinformation har konfigurerats
  • Se till att värd-ID i registret matchar serverinstans-ID i serverresursen (referensbilaga för HostNotConnected-felkod )
  • Samla in loggar

SLBM-klientfel (värdtjänstprovider och klientåtgärder)

  1. [Värd] Kontrollera Debug-NetworkControllerConfigurationState om några LoadBalancer-resurser är i ett feltillstånd. Försök att minimera genom att följa tabellen Åtgärdsobjekt i tillägget.
    1. Kontrollera att det finns en VIP-slutpunkt och annonseringsvägar.
    2. Kontrollera hur många DIP-slutpunkter som har identifierats för VIP-slutpunkten.
  2. [Klient] Verifiera att lastbalanserarens resurser har angetts korrekt.
    1. Verifiera att DIP-slutpunkter som är registrerade i SLBM är värdar för virtuella klientdatorer, vilket motsvarar IP-konfigurationerna för LoadBalancer-serverdelsadresspoolen.
  3. [Värd] Om DIP-slutpunkter inte identifieras eller ansluts:

    1. Check Debug-NetworkControllerConfigurationState

      Kontrollera att NC- och SLB-värdagenten är anslutna till nätverksstyrenhetens händelsekoordinator med hjälp av netstat -anp tcp |findstr 6640).

    2. Checka HostIdin nchostagent tjänstens regkey (referensfelkod HostNotConnected i tillägget) matchar motsvarande serverresurss instans-ID (Get-NCServer |convertto-json -depth 8).

    3. Kontrollera portprofil-ID för den virtuella datorns port matchar motsvarande NIC-resursens instans-ID.

  4. [Värdleverantör] Samla in loggar.

SLB Mux-spårning

Information från Software Load Balancer Muxes kan också fastställas via Prikazivač događaja.

  1. Välj Visa analys- och felsökningsloggar under menyn Prikazivač događaja Visa.
  2. Gå till Program- och tjänstloggar>Microsoft>Windows>SlbMuxDriver>Trace i Prikazivač događaja.
  3. Högerklicka på den och välj Aktivera logg.

Kommentar

Vi rekommenderar att du bara har den här loggningen aktiverad under en kort tid medan du försöker återskapa ett problem.

VFP- och vSwitch-spårning

Från alla Hyper-V-värdar som är värdar för en virtuell gästdator som är ansluten till ett virtuellt klientnätverk kan du samla in en VFP-spårning för att avgöra var problemen kan ligga.

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