Устранение неполадок виртуализации сети Hyper-V (часть 3)

Опубликовано: 19 Марта, 2023

на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в реальном времени

Устранение неполадок виртуализации сети Hyper-V (часть 3)

Введение

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

При обработке исходящего пакета сетевой трафик покидает виртуальную машину, достигает модуля WNV, а затем достигает виртуального сетевого коммутатора. С другой стороны, при обработке входящего пакета виртуальный сетевой коммутатор получает сетевой пакет, отправляет пакет в модуль WNV, а затем обращается к виртуальной машине. В операционных системах Windows Server 2012 и более поздних версиях был добавлен новый параметр NetSh, который можно использовать для включения унифицированной трассировки для захвата входящих и исходящих пакетов. В этой статье мы объясним, как использовать «Унифицированную трассировку» и как она поможет вам выявить основную причину.

В качестве высокоуровневого процесса выполните следующие шаги для устранения неполадок с помощью «Единой трассировки».

Включите унифицированную трассировку для поставщиков, чтобы записывать события в файл ETL.
Воспроизведите проблему сбоя подключения.
Остановить след.
Преобразуйте файл ETL в текстовый файл.
Наконец, проанализируйте файл журнала событий.

Шаг 1. Включите унифицированную трассировку для поставщиков, чтобы записывать события в файл ETL.

Контекст «трассировки Netsh» включает предопределенные наборы поставщиков трассировки. Эти поставщики известны как сценарии, которые можно включить для устранения неполадок. Для отслеживания событий, связанных с виртуализацией сети Hyper-V, доступны два поставщика. Поставщики Microsoft-Windows-Wnv и Microsoft-Windows-Hyper-V-VmSwitch. Поскольку сетевой трафик попадает как на виртуальный сетевой коммутатор, так и на модуль WNV, необходимо включить трассировку на обоих провайдерах. Поскольку одновременно может быть активен только один сеанс трассировки NetSh, необходимо включить трассировку на обоих провайдерах вместе. Чтобы зафиксировать события сетевого виртуального коммутатора и виртуализации сети Hyper-V, выполните приведенную ниже команду NetSh на узле HVHOST-A:

NetSh Trace Start Provider=Microsoft-Windows-WNV Level=5 Provider=Microsoft-Windows-Hyper-V-VmSwitch Capture=Да CaptureType=vmswitch Tracefile=C:TempHNVTrace.etl

Приведенная выше команда включает трассировку для обоих провайдеров вместе, и любые события, которые перехватываются, когда виртуальные машины взаимодействуют друг с другом, сохраняются в файле C:TempHNVTrace.etl. Как указано в приведенной выше команде, трассировка включена для обоих провайдеров; Поставщик «Microsoft-Windows-WNV» для захвата событий, связанных с виртуализацией сети Hyper-V, и поставщик «Microsoft-Windows-Hyper-V-VmSwitch» для захвата событий, происходящих на виртуальном сетевом коммутаторе.

Примечание:
Важно понимать, что включение унифицированной трассировки на HVHOST-A будет фиксировать события, происходящие только на этом узле Hyper-V. Поскольку ВМ1 и ВМ3 расположены на разных узлах Hyper-V, вам может потребоваться включить унифицированную трассировку на HVHOST-B, если вы не обнаружите никаких проблем на стороне HVHOST-A после анализа файла журнала трассировки.

Шаг 2. Воспроизведение проблем с подключением

На шаге 2 все, что вам нужно сделать, это воспроизвести проблемы с подключением или проблему, которая исследуется. Поскольку мы устраняем проблемы со связью между VM1 и VM3, мы будем использовать утилиту ping для проверки подключения от VM1 к VM3. Имейте в виду, что мы включили трассировку на HVHOST-A, поэтому необходимо, чтобы мы пинговали ВМ3 из операционной системы ВМ1. Когда мы пингуем ВМ3 с ВМ1, все исходящие сетевые пакеты будут захвачены в файле C:TempHNVTrace.etl.

Шаг 3 – Остановить трассировку

После завершения выполнения команды Ping остановите трассировку NetSh на узле HVHOST-A Hyper-V. Важно отметить, что нет необходимости тратить много времени на шаг 2. Если вы это сделаете, вы можете увидеть большой файл трассировки событий, который будет трудно читать. Поэтому рекомендуется остановить трассировку как можно быстрее, выполнив следующую команду:

Остановка трассировки NetSh

Шаг 4 — Преобразование файла ETL в текстовый файл

На шаге 4 вам нужно преобразовать файл ETL в текстовый файл. Файл ETL, иногда называемый журналом отслеживания событий, хранит сообщения о событиях. Эти сообщения сохраняются в течение одного или нескольких сеансов трассировки. Хотя вы можете использовать сетевой монитор 3.3 или аналогичные инструменты для чтения содержимого файла ETL, но вам может потребоваться загрузить инструмент сетевого монитора 3.3, прежде чем вы сможете анализировать события из файла ETL. Поскольку NetSh предоставляет возможность преобразования файла ETL в текстовый файл, рекомендуется сделать это, выполнив команду NetSh, как указано ниже:

Преобразование трассировки NetSh C:TempNetTrace.etl C:TempNetTraceOutput.txt

Шаг 5. Наконец, проанализируйте файл журнала событий.

После преобразования файла ETL в текстовый файл откройте текстовый файл с помощью блокнота или аналогичных текстовых редакторов. В файле журнала событий можно увидеть два типа сетевых пакетов; входящие и исходящие сетевые пакеты. Обработка исходящих пакетов происходит, когда модуль Microsoft-Windows-Wnv получает пакет для доставки на виртуальную машину, расположенную на том же или удаленном хосте Hyper-V. Как видно на скриншоте ниже, модуль Microsoft-Windows-Wnv получает пакет, который необходимо доставить на виртуальную машину, расположенную на локальном или удаленном хосте Hyper-V. Модуль Microsoft-Windows-Wnv указывает, что он обрабатывает исходящий сетевой пакет, как показано на снимке экрана ниже:

фигура 1

Точно так же, если модуль Microsoft-Windows-Wnv получает входящий сетевой пакет, вы увидите строку «Входящий пакет разрешения адреса» в файле журнала событий, как показано на снимке экрана ниже.

фигура 2

В рамках устранения неполадок нам необходимо выяснить, что вызывает отбрасывание сетевого пакета модулем Microsoft Microsoft-Windows-WNV.

В рамках обработки пакетов сетевые пакеты будут либо перенаправлены, либо отброшены. Прежде чем вы начнете просматривать файл журнала событий, я бы посоветовал вам поискать записи в файле журнала событий, которые относятся к VM1 и VM3. Что я видел, когда пакет отбрасывался модулем WNV, он регистрировал ключевые слова, такие как «Dropped» или «Drop», в файле журнала событий. Помните, что на шаге 2 мы использовали команду ping для проверки связи VM3 с VM1, чтобы воспроизвести проблему с подключением. Поскольку это исходящий пакет, нам нужно будет найти исходящие записи в файле журнала событий.

Когда модуль Microsoft-Windows-Wnv отбрасывает пакет, он также выделяет причину отбрасывания пакета. Пакет может быть отброшен по нескольким причинам. Одна из причин заключается в том, что в таблице поиска для VM3 или VM1 не настроена запись политики. Другой причиной может быть несоответствие VSID. Как вы можете видеть выделенный текст на снимке экрана ниже, поскольку модуль Microsoft-Windows-Wnv не нашел запись политики в таблице поиска, он отбросил пакет.

Рисунок 3

Примечание:
Важно понимать, что вы не видите имя виртуальной машины в файле журнала событий. Все, что вы видите, это IP-адрес виртуальной машины.

Точно так же, если пакет отброшен из-за несоответствия VSID, модуль Microsoft-Windows-Wnv также укажет на это в файле журнала событий.

Если вам сложно выполнить поиск в файле журнала событий, чтобы найти клавиатуры «причин отключения», вы можете использовать команду «Найти», чтобы отфильтровать записи «причин отключения» и сохранить их в другом текстовом файле. Например, чтобы зафиксировать все «причины удаления» в отдельном текстовом файле, используйте команду ниже:

Найти /I «Причина удаления» < NetTraceOutPut.TXT > AllDropReasons.TXT

После выполнения вышеуказанной команды все записи «причин удаления» будут записаны в файл AllDropReasons.TXT, как показано на снимке экрана ниже.

Рисунок 4

Хотя может быть невозможно охватить все причины в одной статье, но верно то, что включение унифицированной трассировки на узле Hyper-V послужит причиной отбрасывания входящих/исходящих сетевых пакетов модулем Microsoft-Windows-Wnv.

Вывод

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