Устранение неполадок виртуализации сети 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, необходимо включить трассировку на обоих провайдерах вместе.
В качестве высокоуровневого процесса выполните следующие шаги для устранения неполадок с помощью «Единой трассировки».
- Включите Unified Tracing для обоих поставщиков, чтобы записывать события в файл ETL.
- Воспроизведите проблему сбоя подключения или исследуемую проблему.
- Остановить след.
- Преобразуйте файл ETL в текстовый файл.
- Наконец, проанализируйте вывод.
Мы подробно рассмотрим эти шаги в заключительной части этой серии статей.
Резюме
Вторая часть этой серии статей помогла вам узнать еще о нескольких возможностях, которые могут привести к тому, что VM1 и VM3 перестанут взаимодействовать друг с другом. Мы также представили обзор второго подхода к устранению неполадок, который заключается в включении «унифицированной трассировки» в компонентах сетевой виртуализации Hyper-V.
В заключительной части этой серии статей мы увидим, как включение «унифицированной трассировки» в компонентах сетевой виртуализации может помочь вам решить проблемы со связью между виртуальными машинами.
на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в реальном времени