none
Проблема виртуального коммутатора Hyper-V RRS feed

  • Вопрос

  • Добрый день!

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

    Итак, что мы имеем:
    1. Сервер Microsoft Windows Server 2008 R2 SP1 на серверной платформе Intel с единственной настроенной ролью Hyper-V, выступающий в роли хост-системы виртуальных машин.
    2. Три гигабитных сетевых адаптера серверной платформы: два из них серии Intel 82575EBEB , встроенных в материнку (один для LAN ВМ, другой для управления хостом), и один внешний - Intel PRO 1000 PT (прокидывает внешнюю сеть для шлюза, в роли которого выступает одна из ВМ).
    3. Четыре виртуальных машины - сервера Microsoft Windows Server 2008 R2 SP1.
    4. Коммутатор TRENDnet с которым по его гигабитному порту № 25 патч-кордом соединена серверная платформа Intel своим сетевым адаптером для LAN ВМ. Пропускная способность внутренней шины данного коммутатора = 4 Гбит/с.
    5. Локальную сеть Fast Ethernet для рабочих станций.

    Топология сети и скриншоты проблемы приведены в архиве.

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

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






    • Изменено Eurisco 28 июня 2012 г. 11:28
    23 июня 2012 г. 8:30

Ответы

    • Помечено в качестве ответа Eurisco 10 июля 2012 г. 7:38
    23 июня 2012 г. 10:39
    Модератор
  • Выключите все функции Offloading, попробуйте включить VMQ.
    • Помечено в качестве ответа Eurisco 10 июля 2012 г. 7:38
    27 июня 2012 г. 5:39
    Модератор
  • По рассматриваемой проблеме решение найдено:

    1. Установить указанные выше обновления KB2517329 и KB2263829.

    2. Выключить Offloading на хосте:

    3. Включить VMQ на хосте:

    4. Выполнить команды на хосте и во всех виртуальных машинах:

    netsh int ip set global taskoffload=disabled
    netsh interface tcp set global chimney=disabled
    netsh interface tcp set global rss=disabled
    netsh interface tcp set global autotuning=disabled

    • Помечено в качестве ответа Eurisco 10 июля 2012 г. 7:41
    10 июля 2012 г. 7:41

Все ответы

    • Помечено в качестве ответа Eurisco 10 июля 2012 г. 7:38
    23 июня 2012 г. 10:39
    Модератор
  • Обновление KB2263829 было установлено в автоматическом режиме на Hyper-V до публикации данного топика и оно никак не повлияло, а обновление KB2517329 установил сейчас, но проблема сохраняется.



    • Изменено Eurisco 28 июня 2012 г. 6:36
    23 июня 2012 г. 13:10
  • Серверная платформа для физического хоста ВМ приведена здесь.

    У сервера два встроенных гигабитных адаптера Intel 82575EBEB и один внешний гигабитный Intel PRO 1000 PT. Агрегацию каналов не поддерживают (да и поможет ли она в этом случае?).

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

    Может, что-то особенное нужно подкрутить в свойствах сетевого адаптера? Все их привожу ниже.

     

    Остальные свойства адаптера см. в посте ниже.

    • Изменено Eurisco 28 июня 2012 г. 6:37
    27 июня 2012 г. 5:31
  •  
    • Изменено Eurisco 28 июня 2012 г. 6:38
    27 июня 2012 г. 5:34
  • Выключите все функции Offloading, попробуйте включить VMQ.
    • Помечено в качестве ответа Eurisco 10 июля 2012 г. 7:38
    27 июня 2012 г. 5:39
    Модератор
  • Установил Intel ProSet для сетевых интерфейсов - опций сразу добавилось, в том числе появился Teaming, который почему-то работает только для одного из встроенных адаптеров - Intel 82575EB Gigabit - для того, через который осуществляется управление Hyper-V (в двух других адаптерах хоста все компоненты, кроме протокола коммутации виртуальных сетей Microsoft, выключены). Странно, или так должно быть: сначала надо все компоненты включить, а потом объединять в team? Ну да ладно: всё равно пока совместное использование адаптера сети ВМ с хостом Hyper-V не планируется, а четвертого сетевого адаптера нет, поэтому вопросы про teaming пока отложим. Там, кстати, есть вариант настройки в режиме не просто балансировки нагрузки сети (NLB), а в режиме балансировки нагрузки виртуальных машин (VMLB) - кто-нибудь использовал это? Какие рекомендации?

    Также хотелось бы узнать, какие последствия/подводные камни могут быть, если использовать сетевой адаптер, предназначенный для ЛВС ВМ совместно с хостом Hyper-V для его управления (это в случае, если покупка четвертой сетевой карточки для сервера не состоится и придется довольствоваться тем, что есть)?

    Teaming - порядок подключения: оба NIC в один свитч, или в разные? Нет опасности закольцевать Ethernet при неправильном подключении?

    Теперь о главном по теме: все Offloading выключил, VMQ включил:

    В ЦЕЛОМ НЕ РАБОТАЕТ !!! 

    • Изменено Eurisco 28 июня 2012 г. 6:38
    27 июня 2012 г. 20:05
  • В ЧАСТНОСТИ:

    При сливании тяжелого файла с одной из ВМ наружу, с других физических хостов локальной сети не пробиться к ВМ, не участвующим в процессе передачи файлов, т.к. пинги по-прежнему ~ 600-800 мс. Однако включение VMQ позволило немного улучшить взаимодействие между самими ВМ, не участвующими в процессе передачи файлов - пинги между ними через этот виртуальный коммутатор хоть и проскакивают периодически по 500-600 мс, но чаще они стандартные < 1 мс.

    На приведенном ниже скриншоте - пинг Сервера-10 с Сервера-12 через виртуальный коммутатор в момент копирования тяжелого файла с Сервера-11 на ПК-52 в сети.

    Вопрос: как мне всё-таки решить эту проблему, чтобы передача тяжелых файлов с ВМ наружу не сказывалась на производительности остальной сети?


    • Изменено Eurisco 28 июня 2012 г. 9:49
    27 июня 2012 г. 21:50
  • Разные файлы могут передаваться по сети: от аудио, видео и архивов до образов системы, развертываемой через WDS, и виртуальный коммутатор должен справляться с любой нагрузкой, тем более что декларируется его пропускная способность в 10 Гбит/с
    • Изменено Eurisco 28 июня 2012 г. 6:40
    28 июня 2012 г. 6:39
  • Для включения VMQ, помимо настроек в GUI, нужно править реестр.

    28 июня 2012 г. 6:46
    Модератор
  • Если я правильно понял, то для моего физического сетевого адаптера в 1 Гбит/с сначала включаем VMQ with interrupt coalescing через реестр:

    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318\ID /v *MaxRssProcessors /t REG_DWORD /d 1 /f

    reg add  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318\ID /v *RssBaseProcNumber /t REG_DWORD /d 0 /f

    где ID - идентификатор сетевого адаптера, который нужно посмотреть здесь: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318 \

    А затем включаем VMQ:

    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMSMP\Parameters /v BelowTenGigVmqEnabled /t REG_DWORD /d 1 /f

    Верно?

    28 июня 2012 г. 8:03
  • Да.

    Но у меня такое подозрение, что проблема не только в виртуальном коммутаторе.

    28 июня 2012 г. 8:20
    Модератор
  • Здесь есть заминка: параметры *MaxRssProcessors = 8 и *RssBaseProcNumber = 0 у меня уже существуют в реестре для сетевого адаптера и они типа REG_SZ, а не REG_DWORD.

    Более того, параметр BelowTenGigVmqEnabled = 1 уже включен в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMSMP\Parameters

    Должно быть, драйвер сетевой карты Intel всё сам сделал как надо, когда я включил VMQ в его свойствах. Так что, можно констатировать: ситуация к лучшему не изменилась.

    28 июня 2012 г. 8:44
  • Что бы исключить проблему с оборудованием, попробуйте создать виртуальную сеть на основе другого сетевого интерфейса.

    28 июня 2012 г. 8:53
    Модератор
  • Сетевых интерфейсов у меня три, как я писал раньше: два одинаковых Intel 82575EB, встроенные в материнку, и один внешний Intel PRO/1000 PT.

    Попробую сделать локалку для ВМ на основе последнего. Однако в его свойствах нет возможности включить VMQ:

     

    Offloading выключать?

    28 июня 2012 г. 9:30
  • Сделал. Переключил виртуальный коммутатор на другой сетевой адаптер.

    Было:

    Стало:

    28 июня 2012 г. 9:44
  • Не помогает! При копировании тяжелого файла с Сервера-11 на ПК-52 пинги через виртуальный коммутатор с Сервера-12 до Сервера-10 идут плохо. На скриншоте ниже, сделанном на Сервере-12, отчетливо видно, когда начали копировать тяжелый файл.

    28 июня 2012 г. 9:47
  • У Интел, кстати, доступны драйвера, датированные 15 мая 2012 года, у Вас же от 13 ноября 2011. Обновите.
    28 июня 2012 г. 9:58
    Модератор
  • Обновил драйвера и Intel SetPro, VMQ для Intel PRO/1000 PT не появился (наверное, не поддерживается этим адаптером):

     

    28 июня 2012 г. 11:12
  • На скриншоте ниже, сделанном на Сервере-12, отчетливо видно, когда началось копирование тяжелого файла с Сервера-11 на ПК-52 в сети — иллюстрация пингов серверов 10 и 13 с Сервера-12 говорит о том, что обновление драйверов проблему не решило.

    28 июня 2012 г. 11:15
  • А пока решения моей проблемы нет, подскажите:

    1. В свойствах Teaming для сетевого адаптера Intel 82575EB есть вариант настройки в режиме не просто балансировки нагрузки сети (NLB), а в режиме балансировки нагрузки виртуальных машин (VMLB) - кто-нибудь использовал это? Какие рекомендации?

    2. Какие последствия для стабильной работы могут быть, если использовать сетевой адаптер, предназначенный для локальной сети ВМ совместно с хостом Hyper-V для его управления? Где-то я слышал рекомендации о том, что управление Hyper-V желательно делать через отдельный адаптер. Так, как у меня сейчас и сделано.

    3. Какой физический порядок подключения сетевых карт, объединенных в teaming: в один свитч, или в разные? Нет опасности закольцевать Ethernet при неправильном подключении?


    • Изменено Eurisco 28 июня 2012 г. 11:36
    28 июня 2012 г. 11:17
  • У Вас виртуальный коммутатор создан на основе двух адаптеров, объединенных в тим?

    28 июня 2012 г. 11:20
    Модератор
  • Нет. Пока просто интересуюсь.
    28 июня 2012 г. 11:34
  • По рассматриваемой проблеме решение найдено:

    1. Установить указанные выше обновления KB2517329 и KB2263829.

    2. Выключить Offloading на хосте:

    3. Включить VMQ на хосте:

    4. Выполнить команды на хосте и во всех виртуальных машинах:

    netsh int ip set global taskoffload=disabled
    netsh interface tcp set global chimney=disabled
    netsh interface tcp set global rss=disabled
    netsh interface tcp set global autotuning=disabled

    • Помечено в качестве ответа Eurisco 10 июля 2012 г. 7:41
    10 июля 2012 г. 7:41
  • Добрый день! В существует ли решение в такой же ситуации, если хостовая система Server 2012?

    Те же карточки, виртуалки с 2012 сервером работают без проблем, 2008 R2 - также уходит при подключенной сетевой карте в бесконечный Stopping...

    Заранее большое спасибо!

    10 сентября 2013 г. 17:33