Устранение распространенных ошибок Hyper-V (часть 3)

Введение

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

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

Когда пришли новые серверы, я установил Windows Server 2008 R2, присоединил серверы к домену. До этого момента в процессе все, казалось, работало так, как должно. Однако после того, как я установил роль Hyper-V и начал создавать виртуальные машины, начали происходить странные вещи.

Я впервые заметил проблему, когда попытался подключиться к виртуальной машине с помощью удаленного рабочего стола. Windows потребовалась целая вечность, чтобы запустить мой сеанс удаленного рабочего стола. Менее чем через две минуты после того, как я вошел в свою виртуальную машину, мое соединение прервалось.

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

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

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

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

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

Как назло, мой ремонт ничего не изменил. Сервер по-прежнему испытывал всевозможные проблемы с сетевым подключением. Это заставило меня задуматься, не был ли поврежден компонент в стеке TCP/IP.

Вместо того, чтобы пытаться устранить проблему, я принял решение переформатировать все тома сервера и начать с нуля. Я переустановил Windows, а затем применил все последние исправления от Microsoft. Прежде чем тратить время на попытки присоединить сервер к моему домену, я решил выполнить серию диагностических тестов, чтобы убедиться, что мое сетевое подключение работает.

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

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

Обычно Windows Server 2008 привязывает несколько сетевых компонентов непосредственно к сетевому адаптеру. Эти сетевые компоненты включают клиент для сетей Microsoft, планировщик пакетов QoS, общий доступ к файлам и принтерам для сетей Microsoft и протокол Интернета версии 4 (TCP/IPv4). В зависимости от способа настройки сети могут быть дополнительные компоненты, привязанные к сетевому адаптеру, но эти компоненты используются по умолчанию.

Когда Hyper-V установлен и настроен для использования сетевого адаптера, Windows разрывает привязки между сетевым адаптером и компонентами, о которых я только что упоминал. Роль Hyper-V создает виртуальный сетевой коммутатор, привязанный к сетевому адаптеру. На самом деле, если вы посмотрите на свойства адаптера через хост-операционную систему, вы увидите, что единственным компонентом, привязанным к адаптеру, является протокол Microsoft Virtual Network Switch. Вы можете увидеть, как это выглядит на рисунке А.

Рисунок A. Единственный компонент, напрямую привязанный к сетевому адаптеру, — это протокол Microsoft Virtual Network Switch.

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

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

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

Потратив много часов на устранение неполадок, я в конце концов определил, что проблема связана с функцией разгрузки больших посылок (LSO) моего сетевого адаптера. Когда Windows необходимо отправить большой блок данных, она обычно создает серию пакетов, каждый из которых содержит часть отправляемых данных.

Поскольку процесс создания пакета потребляет ресурсы ЦП, некоторые сетевые адаптеры более высокого класса пытаются переложить процесс создания пакета на аппаратное обеспечение. Вместо того, чтобы требовать от Windows создания множества пакетов для больших потоков данных, Windows создает гораздо более крупные пакеты, размер которых может достигать 64 КБ. Когда пакеты достигают сетевой карты, она разбивает пакет на серию кадров, которые можно отправить по сети.

Обычно функция Large Send Offload работает очень хорошо. Однако уровень абстракции, который Hyper-V размещает поверх сетевого адаптера, приводит к сбою функции разгрузки больших отправок. Решение проблемы — просто отключить эту функцию.

Чтобы отключить функцию разгрузки больших файлов, откройте панель управления в операционной системе хоста и перейдите в раздел «Центр управления сетями и общим доступом» | Изменение параметров адаптера. Затем щелкните правой кнопкой мыши список вашего физического сетевого адаптера и выберите команду «Свойства» в появившемся контекстном меню. Когда Windows отобразит страницу свойств сетевого подключения, нажмите кнопку «Настроить». Теперь Windows отобразит страницу свойств сетевого адаптера. Перейдите на вкладку «Дополнительно» на странице свойств и найдите параметр «Разгрузка большой отправки (IPv4)». Наконец, установите значение Disabled, как показано на рисунке B. Нажмите OK, чтобы завершить процесс.

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

Вывод

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