Risolvere i problemi dello stack di rete software-defined di Windows Server

  • Articolo

Questa guida esamina gli errori e gli scenari di errore SDN (Software Defined Networking) comuni e descrive un flusso di lavoro per la risoluzione dei problemi che usa gli strumenti di diagnostica disponibili. Per altre informazioni su SDN, vedere Software Defined Networking.For more information about SDN, see Software Defined Networking.

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versioni 21H2 e 20H2

Tipi di errore

L'elenco seguente rappresenta la classe di problemi più spesso riscontrati con Hyper-V Network Virtualization (HNVv1) in Windows Server 2012 R2 dalle distribuzioni di produzione sul mercato e coincide in molti modi con gli stessi tipi di problemi riscontrati in Windows Server 2016 HNVv2 con il nuovo stack SDN (Software Defined Network).

La maggior parte degli errori può essere classificata in un piccolo set di classi:

  • Configurazione non valida o non supportata

    Un utente richiama l'API NorthBound in modo non corretto o con criteri non validi.

  • Errore nell'applicazione di criteri

    I criteri del controller di rete non sono stati recapitati a un host Hyper-V, ritardati o non aggiornati in tutti gli host Hyper-V (ad esempio, dopo una migrazione in tempo reale).

  • Deviazione della configurazione o bug software

    Problemi relativi al percorso dei dati che comportano l'eliminazione di pacchetti.

  • Errore esterno correlato all'hardware/driver della scheda di interfaccia di rete o all'infrastruttura di rete sottostante

    Comportamento errato degli offload delle attività (ad esempio VMQ) o configurazione non corretta dell'infrastruttura di rete (ad esempio MTU)

    Questa guida alla risoluzione dei problemi esamina ognuna di queste categorie di errori e consiglia le procedure consigliate e gli strumenti di diagnostica disponibili per identificare e correggere l'errore.

Strumenti di diagnostica

Prima di esaminare i flussi di lavoro per la risoluzione dei problemi relativi a ognuno di questi tipi di errori, esaminare gli strumenti di diagnostica disponibili.

Per usare gli strumenti di diagnostica controller di rete (percorso di controllo), è prima necessario installare la RSAT-NetworkController funzionalità e importare il NetworkControllerDiagnostics modulo:

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

Per usare gli strumenti di diagnostica HNV Diagnostics (percorso dati), è necessario importare il HNVDiagnostics modulo:

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

Diagnostica del controller di rete

Questi cmdlet sono documentati in TechNet nel cmdlet Di diagnostica controller di rete. Consentono di identificare i problemi relativi alla coerenza dei criteri di rete nel percorso di controllo tra i nodi del controller di rete e tra il controller di rete e gli agenti host NC in esecuzione negli host Hyper-V.

I Debug-ServiceFabricNodeStatus cmdlet e Get-NetworkControllerReplica devono essere eseguiti da una delle macchine virtuali del nodo controller di rete. Tutti gli altri cmdlet di diagnostica NC possono essere eseguiti da qualsiasi host, che ha connettività al controller di rete e si trova nel gruppo di sicurezza Gestione controller di rete (Kerberos) o ha accesso al certificato X.509 per la gestione del controller di rete.

Diagnostica host Hyper-V

Questi cmdlet sono documentati su TechNet nel cmdlet di diagnostica di Virtualizzazione rete Hyper-V. Consentono di identificare i problemi nel percorso dei dati tra le macchine virtuali tenant (est/ovest) e il traffico in ingresso attraverso un indirizzo VIP SLB (Nord/Sud).

, Debug-VirtualMachineQueueOperation, Get-CustomerRouteGet-PACAMapping, Get-ProviderAddress, Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortIde Test-EncapOverheadSettings sono tutti test locali che possono essere eseguiti da qualsiasi host Hyper-V. Gli altri cmdlet richiamano i test del percorso dei dati tramite il controller di rete e devono quindi accedere al controller di rete come descritto in precedenza.

GitHub

Il repository GitHub Microsoft/SDN include molti script e flussi di lavoro di esempio basati su questi cmdlet predefiniti. In particolare, gli script di diagnostica sono disponibili nella cartella Diagnostica . Aiutaci a contribuire a questi script inviando richieste pull.

Risoluzione dei problemi relativi a flussi di lavoro e guide

[Hoster] Convalidare l'integrità del sistema

Esiste una risorsa incorporata denominata Stato di configurazione in diverse risorse del controller di rete. Lo stato di configurazione fornisce informazioni sull'integrità del sistema, inclusa la coerenza tra la configurazione del controller di rete e lo stato effettivo (in esecuzione) negli host Hyper-V.

Per controllare lo stato di configurazione, eseguire quanto segue da qualsiasi host Hyper-V con connettività al controller di rete.

Nota

Il valore per il NetworkController parametro deve essere il nome di dominio completo o l'indirizzo IP in base al nome del soggetto del certificato X.509 >creato per il controller di rete.

Il Credential parametro deve essere specificato solo se il controller di rete usa l'autenticazione Kerberos (tipica nelle distribuzioni VMM). Le credenziali devono essere per un utente che si trova nel gruppo di sicurezza di gestione del controller di rete.

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

Di seguito è riportato un messaggio di esempio sullo stato della configurazione:

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

Nota

Esiste un bug nel sistema in cui le risorse dell'interfaccia di rete per la scheda di interfaccia di rete della macchina virtuale SLB Mux Transit si trovano in uno stato di errore con errore "Commutatore virtuale - Host non connesso al controller". Questo errore può essere ignorato in modo sicuro se la configurazione IP nella risorsa NIC della macchina virtuale è impostata su un indirizzo IP dal pool IP della rete logica di transito.

È presente un secondo bug nel sistema in cui le risorse dell'interfaccia di rete per le schede di interfaccia di rete del provider HNV gateway si trovano in uno stato di errore con errore "Commutatore virtuale - PortBlocked". Questo errore può essere ignorato anche se la configurazione IP nella risorsa della scheda di interfaccia di rete della macchina virtuale è impostata su Null (per impostazione predefinita).

La tabella seguente mostra l'elenco di codici di errore, messaggi e azioni di completamento da eseguire in base allo stato di configurazione osservato.

Codice Messaggio Azione
Unknown Errore sconosciuto
HostUnreachable Il computer host non è raggiungibile Controllare la connettività di rete di gestione tra controller di rete e host
PAIpAddressExhausted Indirizzi IP pa esauriti Aumentare le dimensioni del pool IP della subnet logica del provider HNV
PAMacAddressExhausted Indirizzi PA Mac esauriti Aumentare l'intervallo di pool Mac
PAAddressConfigurationFailure Impossibile eseguire il plumb degli indirizzi PA nell'host Controllare la connettività di rete di gestione tra controller di rete e host.
CertificateNotTrusted Certificato non attendibile Correggere i certificati usati per la comunicazione con l'host.
CertificateNotAuthorized Certificato non autorizzato Correggere i certificati usati per la comunicazione con l'host.
PolicyConfigurationFailureOnVfp Errore durante la configurazione dei criteri VFP Si tratta di un errore di runtime. Nessuna soluzione alternativa definita. Raccogliere i log.
PolicyConfigurationFailure Errore durante il push dei criteri negli host, a causa di errori di comunicazione o altri errori in NetworkController. Nessuna azione definita. Ciò è dovuto a un errore nell'elaborazione dello stato dell'obiettivo nei moduli controller di rete. Raccogliere i log.
HostNotConnectedToController L'host non è ancora connesso al controller di rete Profilo di porta non applicato all'host o l'host non è raggiungibile dal controller di rete. Verificare che la chiave del Registro di sistema HostID corrisponda all'ID istanza della risorsa server
MultipleVfpEnabledSwitches Sono presenti più commutatori abilitati per VFp nell'host Eliminare uno dei commutatori, poiché l'agente host del controller di rete supporta solo un vSwitch con l'estensione VFP abilitata
PolicyConfigurationFailure Impossibile eseguire il push dei criteri della rete virtuale per una scheda di interfaccia di rete virtuale a causa di errori di connettività o di certificato Verificare se sono stati distribuiti certificati appropriati (il nome del soggetto del certificato deve corrispondere al nome di dominio completo dell'host). Verificare anche la connettività host con il controller di rete
PolicyConfigurationFailure Impossibile eseguire il push dei criteri vSwitch per una scheda di interfaccia di rete virtuale a causa di errori di connettività o di certificato Verificare se sono stati distribuiti certificati appropriati (il nome del soggetto del certificato deve corrispondere al nome di dominio completo dell'host). Verificare anche la connettività host con il controller di rete
PolicyConfigurationFailure Impossibile eseguire il push dei criteri del firewall per una scheda di interfaccia di rete virtuale a causa di errori di connettività o di certificato Verificare se sono stati distribuiti certificati appropriati (il nome del soggetto del certificato deve corrispondere al nome di dominio completo dell'host). Verificare anche la connettività host con il controller di rete
DistributedRouterConfigurationFailure Impossibile configurare le impostazioni del router distribuito nella scheda di interfaccia di rete virtuale dell'host Errore dello stack TCPIP. Potrebbe essere necessario pulire i controller di rete pa e host di ripristino di emergenza nel server in cui è stato segnalato questo errore
DhcpAddressAllocationFailure Allocazione di indirizzi DHCP non riuscita per una scheda di interfaccia di rete della macchina virtuale Controllare se l'attributo dell'indirizzo IP statico è configurato nella risorsa scheda di interfaccia di rete
CertificateNotTrusted
CertificateNotAuthorized		 Impossibile connettersi a Mux a causa di errori di rete o certificato Controllare il codice numerico fornito nel codice del messaggio di errore: corrisponde al codice di errore winsock. Gli errori del certificato sono granulari(ad esempio, non è possibile verificare il certificato, il certificato non è autorizzato e così via)
HostUnreachable MUX è non integro (il caso comune è BGPRouter disconnesso) Il peer BGP nella macchina virtuale RRAS (BGP) o nel commutatore Top-of-Rack (ToR) non è raggiungibile o non esegue correttamente il peering. Controllare le impostazioni BGP sia nella risorsa Software Load Balancer Multiplexer che nel peer BGP (macchina virtuale ToR o RRAS)
HostNotConnectedToController L'agente host SLB non è connesso Verificare che il servizio agente host SLB sia in esecuzione; Fare riferimento ai log dell'agente host SLB (esecuzione automatica) per motivi per cui, nel caso in cui SLBM (NC) abbia rifiutato il certificato presentato dallo stato di esecuzione dell'agente host mostrerà informazioni dettagliate
PortBlocked La porta VFP è bloccata a causa della mancanza di criteri di rete virtuale/ACL Verificare se sono presenti altri errori, che potrebbero causare la mancata configurazione dei criteri.
Overload Loadbalancer MUX è in overload Problema di prestazioni con MUX
RoutePublicationFailure Loadbalancer MUX non è connesso a un router BGP Controllare se mux ha connettività con i router BGP e che il peering BGP sia configurato correttamente
VirtualServerUnreachable Loadbalancer MUX non è connesso a SLB Manager Controllare la connettività tra SLBM e MUX
QosConfigurationFailure Impossibile configurare i criteri QOS Verificare se è disponibile una larghezza di banda sufficiente per tutte le macchine virtuali se viene usata la prenotazione QOS

Controllare la connettività di rete tra il controller di rete e l'host Hyper-V (servizio agente host NC)

Eseguire il netstat comando seguente per verificare che siano presenti tre ESTABLISHED connessioni tra l'agente host NC e i nodi del controller di rete e un LISTENING socket nell'host Hyper-V.

  • ASCOLTO sulla porta TCP:6640 nell'host Hyper-V (servizio agente host NC)
  • Due connessioni stabilite dall'IP host Hyper-V sulla porta 6640 all'IP del nodo NC su porte temporanee (> 32000)
  • Una connessione stabilita dall'IP host Hyper-V sulla porta temporanea all'IP REST del controller di rete sulla porta 6640

Nota

È possibile che siano presenti due connessioni stabilite in un host Hyper-V solo se non sono presenti macchine virtuali tenant distribuite in tale host specifico.

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

Controllare i servizi dell'agente host

Il controller di rete comunica con due servizi dell'agente host negli host Hyper-V: agente host SLB e agente host NC. È possibile che uno o entrambi questi servizi non siano in esecuzione. Controllare lo stato e riavviare se non sono in esecuzione.

Get-Service SlbHostAgent
Get-Service NcHostAgent

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

Controllare l'integrità del controller di rete

Se non sono presenti tre ESTABLISHED connessioni o se il controller di rete non risponde, verificare che tutti i nodi e i moduli di servizio siano attivi e in esecuzione usando i cmdlet seguenti.

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

I moduli del servizio controller di rete sono:

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

Verificare che ReplicaStatus sia Ready e HealthState sia Ok.

In una distribuzione di produzione è con un controller di rete a più nodi, è anche possibile controllare in quale nodo ogni servizio è primario e il relativo stato di replica singola.

Get-NetworkControllerReplica

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

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

Verificare che lo stato della replica sia Pronto per ogni servizio.

Verificare la presenza di id host e certificati corrispondenti tra il controller di rete e ogni host Hyper-V

In un host Hyper-V eseguire i cmdlet seguenti per verificare che l'ID host corrisponda all'ID istanza di una risorsa server nel controller di rete

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

Bonifica

Se si usano script SDNExpress o la distribuzione manuale, aggiornare la chiave HostId nel Registro di sistema in modo che corrisponda all'ID istanza della risorsa server. Riavviare l'agente host del controller di rete nell'host Hyper-V (server fisico) Se si usa VMM, eliminare il server Hyper-V da VMM e rimuovere la chiave del Registro di sistema HostId. Aggiungere quindi di nuovo il server tramite VMM.

Verificare che le identificazioni personali dei certificati X.509 usati dall'host Hyper-V (il nome host sarà il nome soggetto del certificato) per la comunicazione (SouthBound) tra l'host Hyper-V (servizio agente host NC) e i nodi del controller di rete siano gli stessi. Controllare anche che il certificato REST del controller di rete abbia il nome del CN=<FQDN or IP>soggetto .

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

È anche possibile controllare i parametri seguenti di ogni certificato per assicurarsi che il nome del soggetto sia quello previsto (nome host o FQDN REST NC o IP), che il certificato non sia ancora scaduto e che tutte le autorità di certificazione nella catena di certificati siano incluse nell'autorità radice attendibile.

  • Nome soggetto nella riga Subject Name
  • Data di scadenza
  • Attendibile da autorità radice

Se più certificati hanno lo stesso nome soggetto nell'host Hyper-V, l'agente host del controller di rete ne sceglierà casualmente uno da presentare al controller di rete. Questa operazione potrebbe non corrispondere all'identificazione personale della risorsa server nota al controller di rete. In questo caso, eliminare uno dei certificati con lo stesso nome soggetto nell'host Hyper-V e quindi riavviare il servizio Agente host controller di rete. Se non è ancora possibile effettuare una connessione, eliminare l'altro certificato con lo stesso nome soggetto nell'host Hyper-V ed eliminare la risorsa server corrispondente in VMM. Ricreare quindi la risorsa server in VMM, che genererà un nuovo certificato X.509 e lo installerà nell'host Hyper-V.

Controllare lo stato di configurazione del bilanciamento del carico di rete

Lo stato di configurazione SLB può essere determinato come parte dell'output del Debug-NetworkController cmdlet. Questo cmdlet restituisce anche il set corrente di risorse controller di rete nei file JSON, tutte le configurazioni IP da ogni host Hyper-V (server) e i criteri di rete locali dalle tabelle di database dell'agente host.

Per impostazione predefinita, verranno raccolte altre tracce. Per non raccogliere tracce, aggiungere il -IncludeTraces:$false parametro .

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

Nota

Il percorso di output predefinito sarà la <directory working_directory>\NCDiagnostics\. La directory di output predefinita può essere modificata usando il -OutputDirectory parametro .

Le informazioni sullo stato di configurazione SLB sono disponibili nel file diagnostics-slbstateResults.Json in questa directory.

Questo file JSON può essere suddiviso nelle sezioni seguenti:

  • Tessuto
    • SlbmVips: questa sezione elenca l'indirizzo IP dell'indirizzo VIP di SLB Manager, usato dal controller di rete per coordinare la configurazione e l'integrità tra i mux SLB e gli agenti host SLB.
    • MuxState : questa sezione elenca un valore per ogni SLB Mux distribuito, con lo stato del mux
    • Configurazione router: questa sezione elenca il numero di sistema autonomo (ASN) del router upstream (peer BGP), l'indirizzo IP di transito e l'ID. Elencherà anche l'ASN SLB Muxes e l'IP di transito.
    • Informazioni sull'host connesso: questa sezione elenca l'indirizzo IP di gestione di tutti gli host Hyper-V disponibili per eseguire carichi di lavoro con carico bilanciato.
    • Intervalli VIP: questa sezione elenca gli intervalli di pool IP VIP pubblici e privati. L'indirizzo VIP SLBM verrà incluso come INDIRIZZO IP allocato da uno di questi intervalli.
    • Route Mux: questa sezione elenca un valore per ogni mux SLB distribuito contenente tutti gli annunci di route per quel particolare mux.
  • Tenant
    • VipConsolidatedState: questa sezione elenca lo stato di connettività per ogni indirizzo VIP del tenant, inclusi il prefisso di route annunciato, l'host Hyper-V e gli endpoint DIP.

Nota

Lo stato SLB può essere verificato direttamente usando lo script DumpSlbRestState disponibile nel repository Microsoft SDN GitHub.

Convalida del gateway

Dal controller di rete:

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

Dalla macchina virtuale del gateway:

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

Dall'interruttore top of rack (ToR):

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

Router BGP di Windows:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Oltre a questi, dai problemi riscontrati finora (soprattutto nelle distribuzioni basate su SDNExpress), il motivo più comune per cui il raggruppamento di tenant non viene configurato nelle macchine virtuali GW sembra essere il fatto che la capacità GW in FabricConfig.psd1 è inferiore a quella che gli utenti tentano di assegnare al Connections di rete (tunnel S2S) in TenantConfig.psd1. Questa operazione può essere verificata facilmente confrontando gli output dei cmdlet seguenti:

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] Convalidare Data-Plane

Dopo aver distribuito il controller di rete, sono state create reti virtuali tenant e subnet e le macchine virtuali sono state collegate alle subnet virtuali, è possibile eseguire ulteriori test a livello di infrastruttura da parte dell'hoster per controllare la connettività del tenant.

Controllare la connettività di rete logica del provider HNV

Dopo che la prima macchina virtuale guest in esecuzione in un host Hyper-V è stata connessa a una rete virtuale tenant, il controller di rete assegnerà due indirizzi IP del provider HNV (indirizzi IP PA) all'host Hyper-V. Questi indirizzi IP provengono dal pool IP della rete logica del provider HNV e vengono gestiti dal controller di rete. Per scoprire quali sono questi due indirizzi IP HNV:

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

Questi indirizzi IP del provider HNV vengono assegnati alle schede Ethernet create in un raggruppamento di rete TCPIP separato e hanno un nome di scheda VLANX dove X è la VLAN assegnata alla rete logica del provider HNV (trasporto).

La connettività tra due host Hyper-V tramite la rete logica del provider HNV può essere eseguita da un ping con un parametro di raggruppamento aggiuntivo (-c Y) in cui Y è il raggruppamento di rete TCPIP in cui vengono creati i PAhostVNIC. Questo raggruppamento può essere determinato eseguendo:

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

Nota

Gli adattatori della scheda di interfaccia di rete virtuale dell'host PA non vengono usati nel percorso dati e pertanto non hanno un INDIRIZZO IP assegnato all'adattatore "vEthernet (PAhostVNic).

Si supponga, ad esempio, che gli host Hyper-V 1 e 2 abbiano indirizzi IP pa (Provider HNV) di:

Hyper-V Host Indirizzo IP PA 1 Indirizzo IP PA 2
Host 1 10.10.182.64 10.10.182.65
Host 2 10.10.182.66 10.10.182.67

è possibile effettuare il ping tra i due usando il comando seguente per controllare la connettività di rete logica del provider 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

Bonifica

Se il ping del provider HNV non funziona, controllare la connettività di rete fisica, inclusa la configurazione VLAN. Le schede di interfaccia di rete fisiche in ogni host Hyper-V devono essere in modalità trunk senza una VLAN specifica assegnata. La scheda di interfaccia di rete virtuale dell'host di gestione deve essere isolata in base alla VLAN della rete logica di gestione.

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

Controllare il supporto dei frame MTU e jumbo nella rete logica del provider HNV

Un altro problema comune nella rete logica del provider HNV è che le porte di rete fisiche e/o la scheda Ethernet non hanno una MTU sufficientemente grande configurata per gestire l'overhead dall'incapsulamento VXLAN (o NVGRE).

Nota

Alcune schede e driver Ethernet supportano la nuova *EncapOverhead parola chiave che verrà impostata automaticamente dall'agente host del controller di rete su un valore pari a 160. Questo valore verrà quindi aggiunto al valore della parola chiave *JumboPacket la cui somma viene usata come MTU annunciato.

Ad esempio, *EncapOverhead = 160 e *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

Per verificare se la rete logica del provider HNV supporta o meno le dimensioni MTU più grandi end-to-end, usare il Test-LogicalNetworkSupportsJumboPacket cmdlet :

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

Bonifica

  • Regolare le dimensioni MTU sulle porte del commutatore fisico in modo che siano almeno 1674B (inclusi intestazione e trailer Ethernet da 14B)
  • Se la scheda di interfaccia di rete non supporta la parola chiave EncapOverhead, modificare la parola chiave JumboPacket in modo che sia almeno 1674B

Controllare la connettività della scheda di interfaccia di rete della macchina virtuale tenant

Ogni scheda di interfaccia di rete della macchina virtuale assegnata a una macchina virtuale guest ha un mapping CA-PA tra l'indirizzo del cliente privato e lo spazio pa (HNV Provider Address). Questi mapping vengono mantenuti nelle tabelle del server OVSDB in ogni host Hyper-V ed è possibile trovarli eseguendo il cmdlet seguente.

# 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

Nota

Se i mapping CA-PA previsti non vengono restituiti per una determinata macchina virtuale tenant, controllare la scheda di interfaccia di rete della macchina virtuale e le risorse di configurazione IP nel controller di rete usando il Get-NetworkControllerNetworkInterface cmdlet . Controllare anche le connessioni stabilite tra l'agente host NC e i nodi del controller di rete.

Con queste informazioni, il ping di una macchina virtuale tenant può ora essere avviato da Hoster dal controller di rete usando il Test-VirtualNetworkConnection cmdlet .

Scenari di risoluzione dei problemi specifici

Le sezioni seguenti forniscono indicazioni per la risoluzione di scenari specifici.

Nessuna connettività di rete tra due macchine virtuali tenant

  1. [Tenant] Verificare che Windows Firewall nelle macchine virtuali tenant non blocchi il traffico.
  2. [Tenant] Verificare che gli indirizzi IP siano stati assegnati alla macchina virtuale tenant eseguendo ipconfig.
  3. [Hoster] Eseguire Test-VirtualNetworkConnection dall'host Hyper-V per convalidare la connettività tra le due macchine virtuali tenant in questione.

Nota

VSID fa riferimento all'ID subnet virtuale. Nel caso di VXLAN, si tratta dell'identificatore di rete VXLAN (VNI). È possibile trovare questo valore eseguendo il Get-PACAMapping cmdlet .

Esempio

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

Creare il ping CA tra "Green Web VM 1" con IP SenderCA 192.168.1.4 nell'host "sa18n30-2.sa18.nttest.microsoft.com" con IP Mgmt 10.127.132.153 all'INDIRIZZO IP ListenerCA 192.168.1.5 entrambi collegati alla subnet virtuale (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> ...

[Tenant] Verificare che non siano specificati criteri firewall distribuiti nelle interfacce di rete della subnet virtuale o della macchina virtuale che bloccano il traffico.

Eseguire una query sull'API REST del controller di rete disponibile nell'ambiente demo in sa18n30nc nel dominio sa18.nttest.microsoft.com.

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

Esaminare la configurazione IP e le subnet virtuali che fanno riferimento a questo ACL

  1. [Hoster] Eseguire Get-ProviderAddress in entrambi gli host Hyper-V che ospitano le due macchine virtuali tenant in questione e quindi eseguire Test-LogicalNetworkConnection o ping -c <compartment> dall'host Hyper-V per convalidare la connettività nella rete logica del provider HNV
  2. [Hoster] Assicurarsi che le impostazioni MTU siano corrette negli host Hyper-V e nei dispositivi di passaggio di livello 2 tra gli host Hyper-V. Eseguire Test-EncapOverheadValue in tutti gli host Hyper-V in questione. Controllare inoltre che tutti i commutatori di livello 2 compresi tra abbiano MTU impostato su almeno 1674 byte per tenere conto del sovraccarico massimo di 160 byte.
  3. [Hoster] Se gli indirizzi IP PA non sono presenti e/o la connettività ca è interrotta, verificare che i criteri di rete siano stati ricevuti. Eseguire Get-PACAMapping per verificare se le regole di incapsulamento e i mapping CA-PA necessari per la creazione di reti virtuali sovrapposte sono stati stabiliti correttamente.
  4. [Hoster] Verificare che l'agente host del controller di rete sia connesso al controller di rete. A tale scopo, eseguire netstat -anp tcp |findstr 6640.
  5. [Hoster] Verificare che l'ID host in HKLM/ corrisponda all'ID istanza delle risorse del server che ospitano le macchine virtuali tenant.
  6. [Hoster] Verificare che l'ID profilo porta corrisponda all'ID istanza delle interfacce di rete della macchina virtuale delle macchine virtuali tenant.

Registrazione, traccia e diagnostica avanzata

Le sezioni seguenti forniscono informazioni su diagnostica avanzata, registrazione e traccia.

Registrazione centralizzata del controller di rete

Il controller di rete può raccogliere automaticamente i log del debugger e archiviarli in una posizione centralizzata. La raccolta log può essere abilitata quando si distribuisce il controller di rete per la prima volta o in qualsiasi momento successivo. I log vengono raccolti dal controller di rete e dagli elementi di rete gestiti dal controller di rete: computer host, servizi di bilanciamento del carico software (SLB) e computer gateway.

Questi log includono i log di debug per il cluster controller di rete, l'applicazione controller di rete, i log del gateway, il bilanciamento del carico di rete, la rete virtuale e il firewall distribuito. Ogni volta che viene aggiunto un nuovo host/SLB/gateway al controller di rete, la registrazione viene avviata in tali computer. Analogamente, quando un host/SLB/gateway viene rimosso dal controller di rete, la registrazione viene arrestata in tali computer.

Abilitare la registrazione

La registrazione viene abilitata automaticamente quando si installa il cluster controller di rete usando il Install-NetworkControllerCluster cmdlet . Per impostazione predefinita, i log vengono raccolti localmente nei nodi del controller di rete in %systemdrive%\SDNDiagnostics. È consigliabile modificare questo percorso in modo che sia una condivisione file remota (non locale).

I log del cluster del controller di rete vengono archiviati in %programData%\Windows Fabric\log\Traces. È possibile specificare un percorso centralizzato per la raccolta dei log con il DiagnosticLogLocation parametro con la raccomandazione che si tratta anche di una condivisione file remota.

Se si vuole limitare l'accesso a questa posizione, è possibile specificare le credenziali di accesso con il LogLocationCredential parametro . Se si specificano le credenziali per accedere al percorso del log, è necessario specificare anche il CredentialEncryptionCertificate parametro , usato per crittografare le credenziali archiviate localmente nei nodi del controller di rete.

Con le impostazioni predefinite, è consigliabile avere almeno 75 GB di spazio disponibile nella posizione centrale e 25 GB nei nodi locali (se non si usa una posizione centrale) per un cluster controller di rete a tre nodi.

Modificare le impostazioni di registrazione

È possibile modificare le impostazioni di registrazione in qualsiasi momento usando il Set-NetworkControllerDiagnostic cmdlet . È possibile modificare le impostazioni seguenti:

  • Percorso del log centralizzato.

    È possibile modificare il percorso per archiviare tutti i log, con il DiagnosticLogLocation parametro .

  • Credenziali per accedere al percorso del log.

    È possibile modificare le credenziali per accedere al percorso del log, con il LogLocationCredential parametro .

  • Passare alla registrazione locale.

    Se è stata fornita una posizione centralizzata per archiviare i log, è possibile tornare alla registrazione in locale nei nodi del controller di rete con il UseLocalLogLocation parametro (scelta non consigliata a causa di requisiti di spazio su disco di grandi dimensioni).

  • Ambito di registrazione.

    Per impostazione predefinita, vengono raccolti tutti i log. È possibile modificare l'ambito per raccogliere solo i log del cluster del controller di rete.

  • Livello di registrazione.

    Il livello di registrazione predefinito è Informational. È possibile modificarlo in Errore, Avviso o Dettagliato.

  • Tempo di invecchiamento dei log.

    I log vengono archiviati in modo circolare. Per impostazione predefinita, sono disponibili tre giorni di registrazione dei dati, indipendentemente dal fatto che si usi la registrazione locale o la registrazione centralizzata. È possibile modificare questo limite di tempo con il LogTimeLimitInDays parametro .

  • Dimensioni dell'invecchiamento del log.

    Per impostazione predefinita, si avranno al massimo 75 GB di dati di registrazione se si usa la registrazione centralizzata e 25 GB se si usa la registrazione locale. È possibile modificare questo limite con il LogSizeLimitInMBs parametro .

Raccolta di log e tracce

Le distribuzioni VMM usano la registrazione centralizzata per il controller di rete per impostazione predefinita. Il percorso di condivisione file per questi log viene specificato durante la distribuzione del modello di servizio Controller di rete.

Se non è stato specificato un percorso di file, verrà usata la registrazione locale in ogni nodo del controller di rete con i log salvati in C:\Windows\tracing\SDNDiagnostics. Questi log vengono salvati usando la gerarchia seguente:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Tracce

Il controller di rete usa (Azure) Service Fabric. I log di Service Fabric potrebbero essere necessari per la risoluzione di determinati problemi. Questi log sono disponibili in ogni nodo del controller di rete in C:\ProgramData\Microsoft\Service Fabric.

Se un utente ha eseguito il Debug-NetworkController cmdlet, saranno disponibili altri log in ogni host Hyper-V, specificato con una risorsa server nel controller di rete. Questi log (e le tracce se abilitate) vengono conservati in C:\NCDiagnostics.

Diagnostica del bilanciamento del carico di rete

Errori dell'infrastruttura SLBM (azioni del provider di servizi di hosting)

  1. Verificare che Software Load Balancer Manager (SLBM) funzioni e che i livelli di orchestrazione possano comunicare tra loro: SLBM -> SLB Mux e SLBM -> Agenti host SLB. Eseguire DumpSlbRestState da qualsiasi nodo con accesso all'endpoint REST del controller di rete.
  2. Convalidare SDNSLBMPerfCounters in PerfMon in una delle macchine virtuali del nodo Controller di rete (preferibilmente il nodo primario del controller di rete - Get-NetworkControllerReplica):
    1. Il motore Load Balancer (LB) è connesso a SLBM? (SlBM LBEngine Configurations Total > 0)
    2. SLBM è almeno a conoscenza dei propri endpoint? (Totale endpoint> VIP= 2)
    3. Gli host Hyper-V (DIP) sono connessi a SLBM? (Client HP connessi == num server)
    4. SLBM è connesso a Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Verificare che il router BGP configurato stia eseguendo correttamente il peering con SLB MUX.
    1. Se si usa RRAS con Accesso remoto,ovvero macchina virtuale BGP:
      1. Get-BgpPeer dovrebbe mostrare connesso.
      2. Get-BgpRouteInformation deve mostrare almeno una route per l'indirizzo VIP self-service SLBM.
    2. Se si usa l'opzione fisica Top-of-Rack (ToR) come peer BGP, consultare la documentazione:
      1. Ad esempio: # show bgp instance
  4. Convalidare i contatori SlbMuxPerfCounters e SLBMUX in PerfMon nella macchina virtuale SLB Mux.
  5. Controllare lo stato di configurazione e gli intervalli VIP nella risorsa Software Load Balancer Manager.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 Controllare gli intervalli VIP nei pool IP e assicurarsi che slbm self-VIP (LoadBalanacerManagerIPAddress) e tutti i VIP con connessione al tenant si trovino all'interno di questi intervalli.
      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 -

Se uno dei controlli precedenti ha esito negativo, anche lo stato del bilanciamento del carico di rete del tenant sarà in modalità di errore.

Bonifica

In base alle informazioni di diagnostica seguenti presentate, correggere quanto segue:

  • Verificare che i multiplexer SLB siano connessi
    • Risolvere i problemi relativi ai certificati
    • Risolvere i problemi di connettività di rete
  • Verificare che le informazioni sul peering BGP siano configurate correttamente
  • Verificare che l'ID host nel Registro di sistema corrisponda all'ID istanza del server nella risorsa server (appendice di riferimento per il codice di errore HostNotConnected )
  • Raccogliere i log

Errori del tenant SLBM (hosting delle azioni del provider di servizi e del tenant)

  1. [Hoster] Verificare Debug-NetworkControllerConfigurationState se le risorse LoadBalancer sono in stato di errore. Provare a mitigare seguendo la tabella Degli elementi azione nell'appendice.
    1. Verificare che sia presente un endpoint VIP e che siano presenti route pubblicitarie.
    2. Controllare il numero di endpoint DIP individuati per l'endpoint VIP.
  2. [Tenant] Verificare che le risorse Load Balancer siano specificate correttamente.
    1. Convalidare gli endpoint DIP registrati in SLBM che ospitano macchine virtuali tenant, che corrispondono alle configurazioni IP del pool di indirizzi back-end LoadBalancer.
  3. [Hoster] Se gli endpoint DIP non vengono individuati o connessi:

    1. Verifica Debug-NetworkControllerConfigurationState

      Verificare che l'agente host NC e SLB sia connesso correttamente al coordinatore eventi del controller di rete usando netstat -anp tcp |findstr 6640).

    2. nchostagent La HostIdchiave regkey del servizio (codice di errore di riferimento HostNotConnected nell'appendice) corrisponde all'ID istanza della risorsa server corrispondente (Get-NCServer |convertto-json -depth 8).

    3. Controllare che l'ID profilo di porta per la porta della macchina virtuale corrisponda all'ID istanza della risorsa della scheda di interfaccia di rete della macchina virtuale corrispondente.

  4. [Provider di hosting] Raccogliere i log.

SLB Mux tracing

Le informazioni del Software Load Balancer Muxes possono essere determinate anche tramite Visualizzatore eventi.

  1. Selezionare Mostra log di analisi e debug nel menu Visualizzatore eventi Visualizza.
  2. Passare a Registri>>applicazioni e serviziMicrosoftWindows>SlbMuxDriver>Trace in Visualizzatore eventi.
  3. Fare clic con il pulsante destro del mouse e scegliere Abilita log.

Nota

È consigliabile che questa registrazione sia abilitata solo per un breve periodo durante il tentativo di riprodurre un problema.

Traccia VFP e vSwitch

Da qualsiasi host Hyper-V che ospita una macchina virtuale guest collegata a una rete virtuale tenant, è possibile raccogliere una traccia VFP per determinare dove potrebbero trovarsi i problemi.

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