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

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

Введение

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

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

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

• Назначен неправильный адрес провайдера

Адрес поставщика должен быть назначен всем узлам Hyper-V. Адрес PA назначается сетевой карте виртуального сетевого коммутатора, чтобы позволить виртуальным машинам обмениваться данными на физическом уровне. Адрес поставщика можно назначить с помощью командлета SCVMM или HNV PowerShell. Если адрес провайдера не назначен, вся связь с виртуальной машиной будет остановлена. Чтобы получить список адресов провайдеров, настроенных на HVHOSTA и HVHOSTB, выполните приведенную ниже команду на обоих хостах Hyper-V.

• Get-NetVirtualizationProviderAddress | FT ProviderAddress, PrefixLength, InterfaceIndex – AutoSize

Вывод, возвращаемый приведенной выше командой, показан ниже для HVHOSTA:

И когда вы запускаете указанную выше команду на HVHOSTB, вывод должен выглядеть так:

Как видно из выходных данных, возвращаемых HVHOSTA и HVHOSTB, обоим хостам Hyper-V назначаются правильные адреса провайдеров. Если выходные данные не возвращаются должным образом, следует проверить пул PA SCVMM, чтобы убедиться, что для узлов HVHOSTA и HVHOSTB Hyper-V настроены правильные адреса поставщиков, если вы внедрили HNV с помощью SCVMM.

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

• ВМ1 и ВМ3 не подключены к виртуальному коммутатору

Виртуальные машины сами не отключаются от коммутаторов виртуальной сети. Однако рекомендуется убедиться, что виртуальные машины (в данном случае VM1 и VM3) подключены к виртуальному сетевому коммутатору, настроенному для виртуализации сети Hyper-V.

• MAC-адреса не уникальны

Когда виртуальные машины развертываются с помощью SCVMM, SCVMM гарантирует, что виртуальным машинам будут назначены уникальные MAC-адреса. В случае возникновения проблем с подключением всегда проверяйте, чтобы каждой виртуальной машине были назначены уникальные MAC-адреса. Вы можете выполнить командлет PowerShell чтобы получить MAC-адреса, назначенные каждой виртуальной машине.

• WNV не привязан к виртуальному адаптеру

Модуль WNV (Windows Network Virtualization) должен быть привязан к виртуальному адаптеру на всех хостах Hyper-v. Чтобы проверить, привязан ли WNV к сетевому адаптеру, выполните следующую команду на обоих хостах Hyper-V:

• Get-NetAdapterBinding | Где {$_.ComponentID –eq «MS_NetWNV»} | Имя FT, InterfaceDescription, ComponentID -AutoSize

Выполнив приведенную выше команду, вы увидите приведенный ниже вывод для обоих хостов Hyper-V:

Совет:
Поскольку модуль WNV автоматически привязывается к Windows Server 2012 R2, нет необходимости выполнять этот шаг в Hyper-V, работающем на Windows Server 2012 R2.

• Маршрут клиента отсутствует

Маршрут клиента создается для каждой виртуальной подсети. Эти маршруты предоставляют информацию для маршрутизации трафика между виртуальными подсетями в сети виртуальных машин. Чтобы получить список маршрутов клиентов, выполните командлет PowerShell Get-NetVirtualizationCustomerRoute на обоих узлах Hyper-V.

• Get-NetVirtualizationCustomerRoute | FT VirtualSubnetID, DestinationPrefix, NextHop – AutoSize

Вывод, возвращаемый обоими хостами Hyper-V, показан ниже:

Как видно из приведенного выше вывода, маршруты клиентов существуют для обеих виртуальных подсетей (10.0.0.0/24 и 10.0.1.0/24). Можно предположить, что проблем с маршрутами клиентов здесь нет.

• Виртуальные машины используют зарезервированный IP-адрес для шлюза виртуальной подсети.

Виртуальные машины, участвующие в виртуализации сети Hyper-V, не должны использовать зарезервированный IP-адрес для шлюза виртуальной подсети. В HNV адрес виртуальной подсети «.1» зарезервирован HNV для маршрутизации трафика между виртуальными подсетями.

• Физические машины используют адреса провайдеров, назначенные узлам Hyper-V.

Адрес провайдера не должен использоваться какой-либо другой физической машиной, работающей в той же сети. Адреса поставщиков можно назначать с помощью SCVMM или командлета PowerShell. SCVMM гарантирует, что хостам Hyper-V будут назначены уникальные адреса поставщиков. Эти адреса провайдеров назначаются из пула PA, настроенного на SCVMM. Убедитесь, что никакие физические машины в сети не используют эти адреса.

• Виртуальным машинам назначается идентификатор VLAN.

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

• Обновления через сервер VMM не были получены серверами Hyper-V.

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

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

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

• Включение трассировки для компонентов виртуализации сети

Одной из новых функций Windows Server 2012 является «Единая трассировка». Windows Server 2012 и более поздние операционные системы имеют новый параметр NetSh, который можно использовать для захвата трафика виртуальной машины. «Унифицированную трассировку» можно включить, запустив инструмент командной строки NetSh. Контекст « » включает предварительно определенные наборы поставщиков трассировки. Эти поставщики называются сценариями, которые можно включить для устранения неполадок.

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

В виртуализации сети Hyper-V виртуальный трафик покидает виртуальную машину. Нажмите «Модуль сетевой виртуализации WNV», а затем нажмите виртуальный сетевой коммутатор. Поскольку трафик виртуализации сети Hyper-V попадает как на виртуальный сетевой коммутатор, так и на модуль виртуализации сети Windows, и одновременно может быть активна только одна трассировка NetSh, необходимо включить трассировку на обоих провайдерах вместе.

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

1. Включите Unified Tracing для обоих поставщиков, чтобы записывать события в файл ETL.
2. Воспроизведите проблему сбоя подключения или исследуемую проблему.
3. Остановить след.
4. Преобразуйте файл ETL в текстовый файл.
5. Наконец, проанализируйте вывод.

Мы подробно рассмотрим эти шаги в заключительной части этой серии статей.

Резюме

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

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

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