Поделиться через

Устранение неполадок программного обеспечения Windows Server, определенного сетевого стека

  • Статья

В этом руководстве рассматриваются распространенные ошибки программно-определяемой сети (SDN) и сценарии сбоев, а также описан рабочий процесс устранения неполадок, использующий доступные средства диагностики. Дополнительные сведения о SDN см. в разделе "Программное определение сети".

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, версии 21H2 и 20H2

Типы ошибок

В следующем списке представлен класс проблем, наиболее часто встречаемых с виртуализацией сети Hyper-V (HNVv1) в Windows Server 2012 R2 из рабочих развертываний на рынке и совпадает с теми же типами проблем, которые возникают в Windows Server 2016 HNVv2 с новым стеком программно-определяемой сети (SDN).

Большинство ошибок можно классифицировать в небольшой набор классов:

  • Недопустимая или неподдерживаемая конфигурация

    Пользователь вызывает API NorthBound неправильно или с недопустимой политикой.

  • Ошибка в приложении политики

    Политика из сетевого контроллера не была доставлена на узел Hyper-V, отложена или не обновлена на всех узлах Hyper-V (например, после динамической миграции).

  • Смещение конфигурации или ошибка программного обеспечения

    Проблемы с путем передачи данных, приводящие к удаленным пакетам.

  • Внешняя ошибка, связанная с сетевым адаптером или драйверами или подложной сетевой структурой

    Неправильное выполнение задач разгрузки (например, VMQ) или неправильно настроенная сетевая структура подложки (например, MTU)

    Это руководство по устранению неполадок проверяет каждую из этих категорий ошибок и рекомендует рекомендации и средства диагностики, доступные для выявления и исправления ошибки.

Средства диагностики

Прежде чем обсуждать рабочие процессы устранения неполадок для каждого из этих типов ошибок, давайте рассмотрим доступные средства диагностики.

Чтобы использовать средства диагностики сетевого контроллера (путь к элементу NetworkControllerDiagnostics управления), необходимо сначала установить RSAT-NetworkController компонент и импортировать модуль:

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

Чтобы использовать средства диагностики HNV (путь к данным), необходимо импортировать HNVDiagnostics модуль:

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

Диагностика сетевого контроллера

Эти командлеты описаны в TechNet в командлете диагностики сетевого контроллера. Они помогают выявить проблемы согласованности политики сети в пути управления между узлами сетевого контроллера и между сетевым контроллером и агентами узла NC, работающими на узлах Hyper-V.

Get-NetworkControllerReplica Командлеты Debug-ServiceFabricNodeStatus должны выполняться с одной из виртуальных машин узла сетевого контроллера. Все остальные командлеты диагностики NC можно запускать с любого узла, который имеет подключение к сетевому контроллеру и находится в группе безопасности управления сетевыми контроллерами (Kerberos) или имеет доступ к сертификату X.509 для управления сетевым контроллером.

Диагностика узла Hyper-V

Эти командлеты описаны в TechNet в командлете диагностики Виртуализации сети Hyper-V (HNV). Они помогают выявить проблемы в пути к данным между виртуальными машинами клиента (восточная или западная часть) и трафиком входящего трафика через виртуальный IP-адрес SLB (северная или южная часть).

Debug-VirtualMachineQueueOperation, Get-CustomerRoute, , Get-PACAMappingGet-VMSwitchExternalPortIdGet-ProviderAddressGet-VMNetworkAdapterPortIdи Test-EncapOverheadSettings являются всеми локальными тестами, которые можно запускать с любого узла Hyper-V. Другие командлеты вызывают тесты пути к данным через сетевой контроллер и поэтому требуют доступа к сетевому контроллеру, как описано выше.

GitHub

Репозиторий GitHub Microsoft/SDN содержит множество примеров скриптов и рабочих процессов, которые создаются на основе этих встроенных командлетов. В частности, скрипты диагностики можно найти в папке диагностики . Помогите нам внести свой вклад в эти сценарии, отправив запросы на вытягивание.

Устранение неполадок рабочих процессов и руководств

[Hoster] Проверка работоспособности системы

В нескольких ресурсах сетевого контроллера существует внедренный ресурс с именем "Состояние конфигурации". Состояние конфигурации предоставляет сведения о работоспособности системы, включая согласованность между конфигурацией сетевого контроллера и фактическим (запущенным) состоянием на узлах Hyper-V.

Чтобы проверить состояние конфигурации, выполните следующие действия из любого узла Hyper-V с подключением к сетевому контроллеру.

Примечание.

Значением параметра NetworkController должно быть полное доменное имя или IP-адрес на основе имени субъекта сертификата X.509 >, созданного для сетевого контроллера.

Параметр Credential необходимо указать только в том случае, если сетевой контроллер использует проверку подлинности Kerberos (обычно в развертываниях VMM). Учетные данные должны быть для пользователя, который находится в группе безопасности управления сетевыми контроллерами.

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

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

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

Ниже показан пример сообщения о состоянии конфигурации:

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

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

Примечание.

В системе возникает ошибка, из-за которой ресурсы сетевого интерфейса сетевого интерфейса для сетевой карты виртуальной машины мультиплексной подсистемы балансировки нагрузки находятся в состоянии сбоя с ошибкой "Виртуальный коммутатор — узел, не подключенный к контроллеру". Эта ошибка может быть безопасно проигнорирована, если ip-конфигурация в ресурсе сетевой карты виртуальной машины имеет IP-адрес из пула IP-адресов транзитной логической сети.

В системе возникает вторая ошибка, из-за которой ресурсы сетевого интерфейса для сетевых адаптеров поставщика HNV шлюза находятся в состоянии сбоя с ошибкой "Виртуальный коммутатор — портблокирован". Эта ошибка также может быть безопасно проигнорирована, если ip-конфигурация в ресурсе сетевой карты виртуальной машины имеет значение NULL (по проектированию).

В таблице ниже приведен список кодов ошибок, сообщений и дальнейших действий, выполняемых на основе наблюдаемого состояния конфигурации.

Код Сообщение Действие
Неизвестно Неизвестная ошибка
HostUnreachable Хост-компьютер недоступен Проверка сетевого подключения управления между сетевым контроллером и узлом
PAIpAddressExhausted IP-адреса PA исчерпаны Увеличьте размер пула IP-адресов поставщика HNV
PAMacAddressExhausted Адреса PA Mac исчерпаны Увеличение диапазона пула Mac
PAAddressConfigurationFailure Не удалось выполнить сантехнику PA-адресов на узел Проверьте сетевое подключение управления между сетевым контроллером и узлом.
CertificateNotTrusted Сертификат не является доверенным Исправьте сертификаты, используемые для взаимодействия с узлом.
CertificateNotAuthorized Сертификат не авторизован Исправьте сертификаты, используемые для взаимодействия с узлом.
PolicyConfigurationFailureOnVfp Сбой при настройке политик VFP Это сбой среды выполнения. Никаких определенных обходных решений. Сбор журналов.
PolicyConfigurationFailure Сбой при отправке политик на узлы из-за сбоев связи или других ошибок в NetworkController. Никаких определенных действий. Это связано с сбоем в обработке состояния цели в модулях сетевого контроллера. Сбор журналов.
HostNotConnectedToController Узел еще не подключен к сетевому контроллеру Профиль порта не применяется к узлу или узлу недоступен из сетевого контроллера. Убедитесь, что раздел реестра HostID соответствует идентификатору экземпляра ресурса сервера
MultipleVfpEnabledSwitches На узле есть несколько включенных коммутаторов VFp Удалите один из коммутаторов, так как агент узла сетевого контроллера поддерживает только один vSwitch с включенным расширением VFP.
PolicyConfigurationFailure Не удалось отправить политики виртуальной сети для виртуальной карты из-за ошибок сертификата или ошибок подключения Проверьте, были ли развернуты правильные сертификаты (имя субъекта сертификата должно соответствовать полному доменному имени узла). Кроме того, проверьте подключение узла к сетевому контроллеру
PolicyConfigurationFailure Не удалось отправить политики vSwitch для виртуальной карты из-за ошибок сертификата или ошибок подключения Проверьте, были ли развернуты правильные сертификаты (имя субъекта сертификата должно соответствовать полному доменному имени узла). Кроме того, проверьте подключение узла к сетевому контроллеру
PolicyConfigurationFailure Failed to push Firewall policies for a VmNic due to certificate errors or connectivity errors (Не удалось принудительно отправить политики брандмауэра для сетевого адаптера виртуальной машины из-за ошибок сертификата или ошибок подключения) Проверьте, были ли развернуты правильные сертификаты (имя субъекта сертификата должно соответствовать полному доменному имени узла). Кроме того, проверьте подключение узла к сетевому контроллеру
DistributedRouterConfigurationFailure Не удалось настроить параметры распределенного маршрутизатора на виртуальной сетевой сети узла Ошибка стека TCPIP. Возможно, потребуется очистка виртуальных nics узла PA и узла аварийного восстановления на сервере, на котором была зарегистрирована эта ошибка.
DhcpAddressAllocationFailure Сбой выделения DHCP-адресов для виртуальной карты Проверьте, настроен ли атрибут статического IP-адреса в ресурсе сетевого адаптера
CertificateNotTrusted
CertificateNotAuthorized		 Не удалось подключиться к Mux из-за ошибок сети или сертификатов Проверьте числовой код, предоставленный в коде сообщения об ошибке: это соответствует коду ошибки winsock. Ошибки сертификата детализированы (например, сертификат не может быть проверен, сертификат не авторизован и т. д.)
HostUnreachable MUX является неработоспособным (распространенный случай — BGPRouter отключен) Одноранговый узел BGP на виртуальной машине RRAS (виртуальная машина BGP) или переключатель Top-of-Rack (ToR) недоступен или не является успешной пиринговой связью. Проверьте параметры BGP как на ресурсе Многомерного подсистемы балансировки нагрузки программного обеспечения, так и на одноранговом узле BGP (виртуальная машина ToR или RRAS)
HostNotConnectedToController Агент узла SLB не подключен Убедитесь, что служба агента узла SLB запущена; Обратитесь к журналам агента узла SLB (автоматическое выполнение) по причинам, почему, если SLBM (NC) отклонил сертификат, представленный агентом узла, будет отображать сведения о нюансах
PortBlocked Порт VFP заблокирован из-за отсутствия политик виртуальной сети или ACL Проверьте наличие других ошибок, которые могут привести к тому, что политики не настроены.
Перегрузка Многомерная подсистема балансировки нагрузки перегружена Проблема с производительностью многомерных выражений
RoutePublicationFailure Многомерная подсистема балансировки нагрузки не подключена к маршрутизатору BGP Проверьте, имеет ли многомерное подключение к маршрутизаторам BGP и правильно ли настроен пиринг BGP.
VirtualServerUnreachable Подсистема балансировки нагрузки не подключена к диспетчеру балансировки нагрузки Проверка подключения между SLBM и MUX
QosConfigurationFailure Не удалось настроить политики QOS Узнайте, доступна ли достаточная пропускная способность для всех виртуальных машин, если используется резервирование QOS

Проверка сетевого подключения между сетевым контроллером и узлом Hyper-V (служба агента узла NC)

Выполните приведенную netstat ниже команду, чтобы убедиться ESTABLISHED , что между агентом узла NC и узлами сетевого контроллера и одним LISTENING сокетом на узле Hyper-V.

  • ПРОСЛУШИВАНИЕ через порт TCP:6640 на узле Hyper-V (служба агента узла NC)
  • Два установленных подключения от IP-адреса узла Hyper-V через порт 6640 к IP-адресу узла NC на временных портах (> 32000)
  • одно установленное подключение с IP-адреса узла Hyper-V на временном порту к IP-адресу REST сетевого контроллера на порту 6640.

Примечание.

На узле Hyper-V может быть только два установленных подключения, если на этом конкретном узле не развернуты виртуальные машины клиента.

netstat -anp tcp |findstr 6640

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

Проверка служб агента узла

Сетевой контроллер взаимодействует с двумя службами агентов на узлах Hyper-V: агентом узла SLB и агентом узла NC. Возможно, что одна или обе эти службы не выполняются. Проверьте состояние и перезапустите его, если они не запущены.

Get-Service SlbHostAgent
Get-Service NcHostAgent

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

Проверка работоспособности сетевого контроллера

Если нет трех ESTABLISHED подключений или если сетевой контроллер не отвечает, убедитесь, что все узлы и модули служб работают с помощью следующих командлетов.

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

Модули службы сетевого контроллера:

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

Убедитесь, что ReplicaStatus это Ready и HealthState есть Ok.

В рабочем развертывании используется сетевой контроллер с несколькими узлами, можно также проверить, на каком узле каждая служба является основной и ее состоянием отдельной реплики.

Get-NetworkControllerReplica

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

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

Убедитесь, что состояние реплики готово для каждой службы.

Проверка соответствующих идентификаторов узлов и сертификатов между сетевым контроллером и каждым узлом Hyper-V

На узле Hyper-V выполните следующие командлеты, чтобы проверить, соответствует ли hostID идентификатору экземпляра ресурса сервера на сетевом контроллере.

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

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

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

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

Исправление

При использовании скриптов SDNExpress или ручного развертывания обновите раздел HostId в реестре, чтобы он соответствовал идентификатору экземпляра ресурса сервера. Перезапустите агент узла сетевого контроллера на узле Hyper-V (физическом сервере) При использовании VMM удалите сервер Hyper-V из VMM и удалите раздел реестра HostId. Затем снова добавьте сервер через VMM.

Убедитесь, что отпечаток сертификатов X.509, используемых узлом Hyper-V (имя узла будет именем субъекта сертификата) для связи между узлом Hyper-V (служба агента узла NC) и узлами сетевого контроллера совпадают. Кроме того, убедитесь, что rest-сертификат сетевого контроллера имеет имя CN=<FQDN or IP>субъекта.

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

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

dir cert:\\localmachine\root

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

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

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

Вы также можете проверить следующие параметры каждого сертификата, чтобы убедиться, что имя субъекта является ожидаемым (имя узла или полное доменное имя NC REST ИЛИ IP-адрес), сертификат еще не истек, и что все центры сертификации в цепочке сертификатов включены в доверенный корневой центр.

  • Имя субъекта
  • Дата окончания срока действия
  • Доверенный корневым центром

Если несколько сертификатов имеют одно и то же имя субъекта на узле Hyper-V, агент узла сетевого контроллера будет случайным образом выбрать один для представления сетевому контроллеру. Это может не совпадать с отпечатком ресурса сервера, известного сетевому контроллеру. В этом случае удалите один из сертификатов с тем же именем субъекта на узле Hyper-V, а затем перезапустите службу агента узла сетевого контроллера. Если подключение по-прежнему невозможно сделать, удалите другой сертификат с тем же именем субъекта на узле Hyper-V и удалите соответствующий ресурс сервера в VMM. Затем повторно создайте ресурс сервера в VMM, который создаст новый сертификат X.509 и установит его на узле Hyper-V.

Проверка состояния конфигурации SLB

Состояние конфигурации SLB можно определить как часть выходных данных командлета Debug-NetworkController . Этот командлет также выводит текущий набор ресурсов сетевого контроллера в JSON-файлах, все КОНФИГУРАЦИи IP-адресов из каждого узла Hyper-V (сервера) и локальной политики сети из таблиц базы данных агента узла.

Дополнительные трассировки будут собираться по умолчанию. Чтобы не собирать трассировки, добавьте -IncludeTraces:$false параметр.

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

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

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

Примечание.

Расположение выходных данных по умолчанию будет каталогом <working_directory>\NCDiagnostics\. Выходной каталог по умолчанию можно изменить с помощью -OutputDirectory параметра.

Сведения о состоянии конфигурации SLB можно найти в файле диагностика-slbstateResults.Json в этом каталоге.

Этот JSON-файл можно разбить на следующие разделы:

  • Ткань
    • SlbmVips . В этом разделе перечислены IP-адреса виртуального ip-адреса диспетчера балансировки нагрузки, который используется сетевым контроллером для координации конфигурации и работоспособности между подсистемами балансировки нагрузки и агентами узла SLB.
    • MuxState — в этом разделе будет указано одно значение для каждого развернутого мультиплексного подсистемы балансировки нагрузки.
    • Конфигурация маршрутизатора. В этом разделе будет указан номер автономной системы автономной системы (ASN), ip-адрес и идентификатор вышестоящего маршрутизатора. Он также будет перечислять IP-адрес SLB Muxes ASN и транзитного IP-адреса.
    • Сведения о подключенном узле. В этом разделе будет указан IP-адрес управления для всех узлов Hyper-V, доступных для выполнения рабочих нагрузок с балансировкой нагрузки.
    • Диапазоны виртуальных IP-адресов. В этом разделе перечислены диапазоны пулов общедоступных и частных IP-адресов. IP-адрес SLBM будет включен в качестве выделенного IP-адреса из одного из этих диапазонов.
    • Маршруты мультиплекса . В этом разделе будет указано одно значение для каждого развернутого многомерного подсистемы балансировки нагрузки, содержащего все объявления маршрутов для этого конкретного мультиплекса.
  • Съёмщик
    • VipConsolidatedState — в этом разделе перечислены состояния подключения для каждого виртуального ip-адреса клиента, включая префикс объявленного маршрута, узел Hyper-V и конечные точки DIP.

Примечание.

Состояние SLB можно определить непосредственно с помощью скрипта DumpSlbRestState , доступного в репозитории GitHub Microsoft SDN.

Проверка шлюза

Из сетевого контроллера:

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

На виртуальной машине шлюза:

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

Из верхней части переключателя стойки (ToR):

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

Маршрутизатор BGP Для Windows:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

В дополнение к этим проблемам, которые мы видели до сих пор (особенно в развертываниях на основе SDNExpress), наиболее распространенная причина того, что отсек клиента не настраивается на виртуальных машинах GW, кажется, тот факт, что емкость GW в FabricConfig.psd1 меньше по сравнению с тем, что люди пытаются назначить сетевым подключениям (S2S Tunnels) в TenantConfig.psd1. Это можно легко проверить, сравнивая выходные данные следующих командлетов:

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] Проверка плоскости данных

После развертывания сетевого контроллера виртуальные сети и подсети клиента были созданы, а виртуальные машины подключены к виртуальным подсетям, дополнительные тесты уровня структуры могут выполняться узлом для проверки подключения клиента.

Проверка логического сетевого подключения поставщика HNV

После подключения первой гостевой виртуальной машины на узле Hyper-V к виртуальной сети клиента сетевой контроллер назначит два IP-адреса поставщика HNV (IP-адреса PA) узлу Hyper-V. Эти IP-адреса будут поступать из пула IP-адресов логической сети поставщика HNV и управляться сетевым контроллером. Чтобы узнать, что такое два 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

Эти IP-адреса поставщика HNV (IP-адреса PA) назначаются адаптерам Ethernet, созданным в отдельном сетевом отсеке TCPIP, и имеют имя адаптера VLANX , где X является виртуальной локальной сетью, назначенной поставщику HNV (транспорт).

Подключение между двумя узлами Hyper-V с помощью логической сети поставщика HNV можно выполнить путем проверки связи с дополнительным параметром (-c Y), где Y — это сетевой отсек TCPIP, в котором создаются PAhostVNICs. Этот отсек можно определить путем выполнения:

C:\> ipconfig /allcompartments /all

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

Ethernet adapter VLAN11:

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

Ethernet adapter VLAN11:

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

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

Примечание.

Адаптеры виртуальных сетевых адаптеров узла PA не используются в пути к данным и поэтому не имеют IP-адреса, назначенного адаптеру vEthernet (PAhostVNic).

Например, предположим, что узлы Hyper-V 1 и 2 имеют IP-адреса поставщика HNV (PA):

Узел Hyper-V IP-адрес PA 1 IP-адрес PA 2
Узел 1 10.10.182.64 10.10.182.65
Узел 2 10.10.182.66 10.10.182.67

Для проверки логического сетевого подключения поставщика HNV можно проверить связь между ними с помощью следующей команды.

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

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

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

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

Исправление

Если связь поставщика HNV не работает, проверьте подключение к физической сети, включая конфигурацию виртуальной локальной сети. Физические сетевые адаптеры на каждом узле Hyper-V должны находиться в режиме магистрали без определенной виртуальной локальной сети. Виртуальная сетевая карта узла управления должна быть изолирована от виртуальной сети логической сети управления.

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

Проверка поддержки MTU и кадра jumbo в логической сети поставщика HNV

Еще одна распространенная проблема в логической сети поставщика HNV заключается в том, что физические сетевые порты и /или ethernet-карта не имеют достаточно большого MTU, настроенного для обработки затрат от инкапсуляции VXLAN (или NVGRE).

Примечание.

Некоторые карты Ethernet и драйверы поддерживают новое *EncapOverhead ключевое слово, которое автоматически устанавливается агентом узла сетевого контроллера значение 160. Затем это значение будет добавлено в значение ключевого слова *JumboPacket, суммирование которого используется в качестве объявленного MTU.

Например, *EncapOverhead = 160 и *JumboPacket = 1514 => MTU = 1674B

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

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

Чтобы проверить, поддерживает ли логическая сеть поставщика HNV более крупный размер MTU, используйте Test-LogicalNetworkSupportsJumboPacket командлет:

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

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

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

Исправление

  • Настройте размер MTU на портах физического коммутатора, чтобы иметь по крайней мере 1674B (включая 14B заголовок и трейлер Ethernet).
  • Если карточка сетевого адаптера не поддерживает ключевое слово EncapOverhead, измените ключевое слово JumboPacket как минимум 1674B

Проверка подключения сетевого адаптера виртуальной машины клиента

Каждый сетевой адаптер виртуальной машины, назначенный гостевой виртуальной машине, имеет сопоставление ЦС между частным адресом клиента (ЦС) и пространством HNV Provider Address (PA). Эти сопоставления хранятся в таблицах серверов OVSDB на каждом узле Hyper-V и могут быть найдены, выполнив следующий командлет.

# 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

Примечание.

Если ожидаемые сопоставления ЦС-PA не отображаются для данной виртуальной машины клиента, проверьте ресурсы сетевой карты и IP-конфигурации виртуальной машины на сетевом контроллере с помощью командлета Get-NetworkControllerNetworkInterface . Кроме того, проверьте установленные подключения между агентом узла NC и узлами сетевого контроллера.

С помощью этих сведений связь с виртуальной машиной клиента теперь может быть инициирована хост-администратором из сетевого контроллера с помощью командлета Test-VirtualNetworkConnection .

Конкретные сценарии устранения неполадок

В следующих разделах приведены рекомендации по устранению неполадок в определенных сценариях.

Нет сетевого подключения между двумя виртуальными машинами клиента

  1. [клиент] Убедитесь, что брандмауэр Windows в виртуальных машинах клиента не блокирует трафик.
  2. [клиент] Убедитесь, что IP-адреса назначены виртуальной машине клиента, выполнив команду ipconfig.
  3. [Hoster] Запустите Test-VirtualNetworkConnection с узла Hyper-V, чтобы проверить подключение между двумя виртуальными машинами клиента.

Примечание.

VSID ссылается на идентификатор виртуальной подсети. В случае VXLAN это сетевой идентификатор VXLAN (VNI). Это значение можно найти, выполнив Get-PACAMapping командлет.

Пример

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

Создайте ca-ping между "зеленой веб-виртуальной машиной 1" с IP-адресом SenderCA 192.168.1.4 на узле "sa18n30-2.sa18.nttest.microsoft.com" с IP-адресом Mgmt 10.127.132.153 для прослушивателя IP-адреса 192.168.1.5, подключенных к виртуальной подсети (VSID) 4114.

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

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

CA Routing Information:

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

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[клиент] Убедитесь, что в виртуальной подсети или сетевых интерфейсах виртуальной машины нет политик распределенного брандмауэра, которые блокируют трафик.

Запрос REST API сетевого контроллера, найденный в демонстрационной среде в sa18n30nc в домене sa18.nttest.microsoft.com.

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

Просмотрите IP-конфигурацию и виртуальные подсети, ссылающиеся на этот ACL

  1. [Hoster] Запустите Get-ProviderAddress на обоих узлах Hyper-V, на которых размещены две виртуальные машины клиента, а затем запустите Test-LogicalNetworkConnection узел ping -c <compartment> Hyper-V, чтобы проверить подключение к логической сети поставщика HNV.
  2. [Hoster] Убедитесь, что параметры MTU правильны на узлах Hyper-V и устройствах уровня 2 переключения между узлами Hyper-V. Запустите Test-EncapOverheadValue все узлы Hyper-V, которые имеются в вопросе. Кроме того, убедитесь, что все коммутаторы уровня 2 между MTU имеют значение не менее 1674 байт, чтобы учитывать максимальные затраты на 160 байт.
  3. [Hoster] Если IP-адреса PA отсутствуют и (или) подключение К ЦС нарушено, убедитесь, что политика сети получена. Выполните команду Get-PACAMapping , чтобы узнать, правильно ли установлены правила инкапсуляции и сопоставления ЦС-PA, необходимые для создания наложенных виртуальных сетей.
  4. [Hoster] Убедитесь, что агент узла сетевого контроллера подключен к сетевому контроллеру. Для этого выполните команду netstat -anp tcp |findstr 6640.
  5. [Hoster] Убедитесь, что идентификатор узла в HKLM/ соответствует идентификатору экземпляра ресурсов сервера, на которых размещены виртуальные машины клиента.
  6. [Hoster] Убедитесь, что идентификатор профиля порта соответствует идентификатору экземпляра сетевых интерфейсов виртуальной машины виртуальных машин клиента.

Ведение журнала, трассировка и расширенные диагностика

В следующих разделах содержатся сведения о расширенных диагностика, ведения журнала и трассировке.

Централизованное ведение журнала сетевого контроллера

Сетевой контроллер может автоматически собирать журналы отладчика и хранить их в централизованном расположении. Сбор журналов можно включить при первом развертывании сетевого контроллера или в любое время позже. Журналы собираются из сетевого контроллера и сетевых элементов, управляемых сетевым контроллером: хост-компьютеры, подсистемы балансировки нагрузки программного обеспечения (SLB) и компьютеры шлюза.

Эти журналы включают журналы отладки для кластера сетевого контроллера, приложения сетевого контроллера, журналов шлюза, SLB, виртуальной сети и распределенного брандмауэра. При каждом добавлении нового узла или шлюза на сетевой контроллер на этих компьютерах запускается ведение журнала. Аналогичным образом, когда узел/шлюз удаляется из сетевого контроллера, ведение журнала останавливается на этих компьютерах.

Включение ведения журналов

Ведение журнала автоматически включено при установке кластера сетевого контроллера с помощью командлета Install-NetworkControllerCluster . По умолчанию журналы собираются локально на узлах сетевого контроллера по адресу %systemdrive%\SDNDiagnostics. Рекомендуется изменить это расположение на удаленный файловый ресурс (а не локальный).

Журналы кластера сетевого контроллера хранятся в папке %programData%\Windows Fabric\log\Traces. Вы можете указать централизованное расположение для сбора журналов с DiagnosticLogLocation параметром с рекомендацией о том, что это также удаленный файловый ресурс.

Если вы хотите ограничить доступ к этому расположению, вы можете указать учетные данные доступа с параметром LogLocationCredential . Если вы предоставляете учетные данные для доступа к расположению журнала, необходимо также указать CredentialEncryptionCertificate параметр, который используется для шифрования учетных данных, хранящихся локально на узлах сетевого контроллера.

При использовании параметров по умолчанию рекомендуется иметь не менее 75 ГБ свободного места в центральном расположении и 25 ГБ на локальных узлах (если они не используют центральное расположение) для кластера сетевого контроллера с тремя узлами.

Изменение параметров ведения журнала

Параметры ведения журнала можно изменить в любое время с помощью командлета Set-NetworkControllerDiagnostic . Можно изменить следующие параметры:

  • Централизованное расположение журнала.

    Вы можете изменить расположение для хранения всех журналов с параметром DiagnosticLogLocation .

  • Учетные данные для доступа к расположению журнала.

    Вы можете изменить учетные данные для доступа к расположению журнала с параметром LogLocationCredential .

  • Перейдите в локальное ведение журнала.

    Если вы предоставили централизованное расположение для хранения журналов, вы можете вернуться к ведению журнала локально на узлах сетевого контроллера с UseLocalLogLocation параметром (не рекомендуется из-за требований к большому объему дискового пространства).

  • Область ведения журнала.

    По умолчанию собираются все журналы. Область можно изменить, чтобы собирать только журналы кластера сетевого контроллера.

  • Уровень ведения журнала.

    Уровень ведения журнала по умолчанию — информационный. Его можно изменить на Error, Warning или Verbose.

  • Время хранения журнала.

    Журналы хранятся в циклической форме. По умолчанию у вас есть три дня ведения журнала, независимо от того, используется ли локальное ведение журнала или централизованное ведение журнала. Это ограничение времени можно изменить с LogTimeLimitInDays помощью параметра.

  • Размер ведения журнала.

    По умолчанию у вас будет не более 75 ГБ данных ведения журнала, если используется централизованное ведение журнала и 25 ГБ при использовании локального ведения журнала. Это ограничение можно изменить с LogSizeLimitInMBs помощью параметра.

Сбор журналов и трассировок

Развертывания VMM используют централизованное ведение журнала для сетевого контроллера по умолчанию. Расположение общей папки для этих журналов указывается при развертывании шаблона службы сетевого контроллера.

Если расположение файла не указано, локальное ведение журнала будет использоваться на каждом узле сетевого контроллера с журналами, сохраненными в папке C:\Windows\tracing\SDNDiagnostics. Эти журналы сохраняются с помощью следующей иерархии:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Трассировки

Сетевой контроллер использует Service Fabric (Azure). Журналы Service Fabric могут потребоваться при устранении определенных проблем. Эти журналы можно найти на каждом узле сетевого контроллера в C:\ProgramData\Microsoft\Service Fabric.

Если пользователь запускает Debug-NetworkController командлет, дополнительные журналы будут доступны на каждом узле Hyper-V, который был указан с ресурсом сервера в сетевом контроллере. Эти журналы (и трассировки, если они включены) хранятся в C:\NCDiagnostics.

Диагностика SLB

Ошибки структуры SLBM (действия поставщика услуг размещения)

  1. Убедитесь, что диспетчер балансировки нагрузки программного обеспечения (SLBM) работает и что уровни оркестрации могут взаимодействовать друг с другом: SLBM -> SLB Mux и SLBM —> агенты узла SLB. Запустите DumpSlbRestState с любого узла с доступом к конечной точке REST контроллера сети.
  2. Проверьте SDNSLBMPerfCounters в PerfMon на одной из виртуальных машин узла сетевого контроллера (предпочтительно основной узел сетевого контроллера — Get-NetworkControllerReplica):
    1. Подключен ли подсистема Load Balancer (LB) к SLBM? (В общей сложности > конфигурации SLBM LBEngine 0)
    2. Не знает ли SLBM по крайней мере о своих собственных конечных точках? (Итог> конечных точек ВИРТУАЛЬНЫх IP-адресов= 2)
    3. Подключены ли узлы Hyper-V (DIP) к SLBM? (клиенты HP, подключенные == числовые серверы)
    4. Подключен ли SLBM к Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Убедитесь, что маршрутизатор BGP настроен успешно пиринга с многомерным модулом балансировки нагрузки.
    1. Если используется RRAS с удаленным доступом (то есть виртуальная машина BGP):
      1. Get-BgpPeer должно отображаться подключено.
      2. Get-BgpRouteInformation должен показать по крайней мере маршрут для самостоятельного ВИРТУАЛЬНОго IP-адреса SLBM.
    2. При использовании физического коммутатора top-of-Rack (ToR) в качестве однорангового узла BGP обратитесь к документации:
      1. Например: # show bgp instance
  4. Проверьте счетчики SlbMuxPerfCounters и SLBMUX в PerfMon на виртуальной машине SLB Mux.
  5. Проверьте состояние конфигурации и диапазоны ВИРТУАЛЬНЫх IP-адресов в ресурсе Software Load Balancer Manager.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (проверьте диапазоны ВИРТУАЛЬНЫх IP-адресов в пулах IP-адресов и убедитесь, что slBM self-VIP (LoadBalanacerManagerIPAddress) и все виртуальные IP-адреса, подключенные к клиенту, находятся в пределах этих диапазонов)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

Если какая-либо из указанных выше проверок завершается ошибкой, состояние SLB клиента также будет находиться в режиме сбоя.

Исправление

На основе приведенных ниже диагностических сведений исправьте следующее:

  • Убедитесь, что мультиплексоры SLB подключены
    • Устранение проблем с сертификатом
    • Исправление сетевых неполадок
  • Убедитесь, что данные пиринга BGP успешно настроены
  • Убедитесь, что идентификатор узла в реестре соответствует идентификатору экземпляра сервера в ресурсе сервера (справочник по коду ошибки HostNotConnected )
  • Сбор журналов

Ошибки клиента SLBM (действия поставщика услуг размещения и клиента)

  1. [Hoster] Проверьте Debug-NetworkControllerConfigurationState , находятся ли ресурсы LoadBalancer в состоянии ошибки. Попробуйте устранить проблему, выполнив таблицу элементов действия в приложении.
    1. Убедитесь, что конечная точка ВИРТУАЛЬНОго IP-адреса присутствует и рекламные маршруты.
    2. Проверьте, сколько конечных точек DIP обнаружено для конечной точки ВИРТУАЛЬНОго IP-адреса.
  2. [клиент] Проверьте правильность указания ресурсов Load Balancer.
    1. Проверьте конечные точки DIP, зарегистрированные в SLBM, размещают виртуальные машины клиента, соответствующие конфигурации IP-адресов внутреннего пула адресов LoadBalancer.
  3. [Hoster] Если конечные точки DIP не обнаружены или подключены:

    1. Проверка Debug-NetworkControllerConfigurationState

      Убедитесь, что агент узла NC и SLB успешно подключен к координатору событий сетевого контроллера с помощью netstat -anp tcp |findstr 6640).

    2. Проверка HostIdregkey службы (ссылочный HostNotConnected код ошибки в приложении) соответствует соответствующему идентификатору экземпляра ресурса сервера (Get-NCServer |convertto-json -depth 8).nchostagent

    3. Проверьте идентификатор профиля порта для порта виртуальной машины, соответствующий идентификатору экземпляра сетевого адаптера виртуальной машины.

  4. [Поставщик размещения] Сбор журналов.

Трассировка мультиплексного подсистемы балансировки нагрузки

Сведения о подсистеме балансировки нагрузки программного обеспечения также можно определить с помощью Просмотр событий.

  1. Выберите "Показать журналы аналитики и отладки" в меню "Вид Просмотр событий".
  2. Перейдите к журналам>приложений и служб Трассировки Microsoft>Windows>SlbMuxDriver>в Просмотр событий.
  3. Щелкните его правой кнопкой мыши и выберите "Включить журнал".

Примечание.

Рекомендуется включить только это ведение журнала в течение короткого времени при попытке воспроизвести проблему.

Трассировка VFP и vSwitch

Из любого узла Hyper-V, на котором размещена гостевая виртуальная машина, подключенная к виртуальной сети клиента, можно собрать трассировку VFP, чтобы определить, где могут возникнуть проблемы.

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