В локальной сети организации находятся сервер и коммутатор, соединенные патч-кордом. Необходимо настроить IP-адрес у сервера с ОС Windows Server (хост) и у виртуальных машин, работающих на нём. Виртуальные машины должны быть подключены в разные VLAN.

В сервере предварительно выполнена типовая настройка для работы виртуальных машин. Первоначальная настройка Hyper-V тут.

В сервер установлен сетевой адаптер для SFP+ подключения. Настройки VLAN будут выполняться на нем.

Коммутатор может быть абсолютно любой, главное чтоб выполнялось условие – порт коммутатора к серверу настроен в режиме Trunk.

 

Используемые понятия.

Хост – это физический сервер (компьютер), на котором установлено и работает программное обеспечение.

Гипервизор – это программный слой, который создаёт и управляет виртуальными машинами.

Hyper-V – это гипервизор типа 1 от Microsoft, который превращает хост в среду для работы виртуальных машин.

Два основных типа гипервизоров.

Аппаратный (bare-metal, тип 1) – работает напрямую на «железе», заменяя собой ОС. Пример: Hyper-V, VMware ESXi, Proxmox.

Программный (hosted, тип 2) – работает как приложение внутри ОС. Пример: VMware Workstation, VirtualBox.

Hyper-V – это гипервизор типа 1 (аппаратный), несмотря на то, что его устанавливают поверх Windows. Когда мы включаем роль Hyper-V в Windows, ядро Hyper-V загружается самым первым, ещё до загрузки основной Windows. Гипервизор встраивается между оборудованием и всей операционной системой. Сама Windows при этом становится управляющей операционной системой (Management OS) и работает поверх гипервизора наравне с виртуальными машинами, но с расширенными правами управления. Hyper-V не является приложением внутри Windows.

 

Настройка сервера.

Панель управления >> Сеть и Интернет >> Сетевые подключения.

Подписываем название сетевого адаптера.

Через CLI (PowerShell с правами администратора).

Выводим список сетевых адаптеров.

 

Находим нужный адаптер и переименовываем.

 

Переходим в диспетчер виртуальных коммутаторов Hyper-V.

 

Создаем новый виртуальный коммутатор для внешней сети.

Настраиваем.

Имя – любое понятное.

Тип подключения: внешняя сеть – выбираем запланированный физический сетевой адаптер.

Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру – активировано по умолчанию.

в PowerShell это:

AllowManagementOS – настройка виртуального коммутатора Hyper-V, которая разрешает операционной системе гипервизора (Management OS) использовать этот сетевой адаптер для подключения к сети.

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

При выключении: сетевой адаптер доступен только виртуальным машинам, хост не использует его.

Тоесть, при активации этой настройки создаётся виртуальный сетевой адаптер на Management OS, позволяющий хосту использовать физический NIC через виртуальный коммутатор, чтобы Windows Server мог получать IP-адрес и работать в сети.

 

VLAN ID – Разрешить идентификацию виртуальной локальной сети для управляющей операционной системы – активируем.

в PowerShell это:

Указываем VLAN, из которого хотим, чтоб хост получал IP-адрес.

Это значит виртуальный адаптер Management OS, который связан с этим виртуальным коммутатором, будет помечать (или принимать) трафик с указанным VLAN ID. Hyper-V (гипервизор) может работать в одной конкретной VLAN, даже если виртуальный коммутатор подключён к порту trunk в ответном коммутаторе.

Если виртуальный коммутатор подключён к trunk-порту на коммутаторе, то трафик Management OS нужно явно поймать через VLAN ID.

Для VM можно настроить trunk с разрешением множества VLAN.

 

Через CLI.

Создаем виртуальный коммутатор.

 

Активируем VLAN и настраиваем его номер.

После этих настроек виртуальный коммутатор через физический адаптер получит IP-адрес из указанного VLAN.

 

Management OS – это сама Windows Server, которая установлена как гипервизор Hyper-V, а не какие-либо виртуальные машины.

В Hyper-V PowerShell -ManagementOS – это параметр командлетов, который указывает, что действие нужно выполнить не на виртуальной машине, а на самом гипервизоре (то есть на Management Operating System).

В Hyper-V один физический NIC может использоваться одновременно для Management OS и для VM через виртуальный коммутатор. Без -ManagementOS команда настроит VLAN только на виртуальной машине. С -ManagementOS мы можем сделать так, чтобы гипервизор получил IP в нужном VLAN. Изолировать трафик гипервизора от трафика VM (каждой VM можно назначить свои VLAN). Работать с trunk-портом на коммутаторе, где гипервизор должен видеть только один конкретный VLAN.

Просмотр того, что было настроено.

Сначала разрешаем Management OS использовать виртуальный коммутатор (-AllowManagementOS).

Потом, при необходимости, назначаем VLAN (Set-VMNetworkAdapterVlan).

 

Возврат настроек в исходное состояние (т.е. без VLAN).

 

Настройка сети для ВМ.

В виртуальной машине можно принимать как Access так и Trunk.

Access – для VM, которая будет работать только в одном VLAN.

Trunk – для VM, которая должна принимать несколько VLAN одновременно (например, маршрутизатор или коммутатор виртуальный).

До начала настроек установлен режим Untagged. VM сейчас не в каком-либо VLAN и получает трафик native VLAN виртуального коммутатора.

 

Access.

Это основной вариант, с которым в нашей сети настроены все ВМ.

Для примера настроим произвольную ВМ на получение VLAN с тэгом 60. Переходим в параметры ВМ. 

 

Подключаем существующий адаптера ВМ к виртуальному коммутатору.

Разрешить идентификацию виртуальной локальной сети – активируем.

Указываем VLAN с которым должна работать ВМ.

 

Заходим в ВМ (Ubuntu). Проверяем – виртуальной машине раздался IP-адрес из планируемой VLAN.

Через CLI.

Подключение существующего адаптера к виртуальному коммутатору.

-VMName – название виртуальной машины.

-Name – название виртуального адаптера VM (Get-VMNetworkAdapter показывает все адаптеры).

-SwitchName – название нужного виртуального коммутатора (vSW-SFP+).

 

Исходное состояние.

Назначение VLAN.

 

Проверка.

Параметр IsManagementOs показывает, кто использует этот виртуальный сетевой адаптер.

True – адаптер принадлежит управляющей операционной системе (Management OS), т.е. физическому хосту Hyper-V.

False  – адаптер принадлежит виртуальной машине, т.е. гостевой ОС, в данном случае ZABBIX. (используется только внутри VM). Все VLAN-настройки будут применяться к этой VM, а не к Management OS.

 

Проверка VLAN настроек.

Виртуальная машина подключена в режиме Access. Весь её трафик помечен как VLAN60.

 

 

Просмотр настроек VLAN у всех ВМ сразу.

Настройка ВМ с VLAN в режиме access завершена. Нет ни чего сложного.

 

Trunk.

ВМ с настройкой транка используется реже. Рассмотрим этот вариант для понимания.

В режиме Trunk галочка в GUI не применяется. GUI-настройка: «Разрешить идентификацию виртуальной локальной сети» относится только к режиму access, когда у ВМ один VLAN.

ВМ может работать в VLAN при режиме Trunk. Это корректно. Но задавать VLAN нужно внутри ВМ, а не в Hyper-V. Hyper-V только пропускает трафик нужных VLAN через trunk.

 

Команда назначающая транк.

Ноль означает, что нет нетегированного (native) VLAN, всё будет только в тегах.

Адаптер виртуальной машины ZABBIX работает в режиме Trunk принимает трафик VLAN 10, 20, 60 и также принимает нетегированный трафик (native VLAN 0). Т.е. ВМ может использовать сразу 3 VLAN (и один без тега), если внутри ОС настроено VLAN-тегирование.

 

Команда PowerShell если нужен транк всех VLAN и нативный VLAN с тэгом например 10. Тоесть не тегированный трафик ВМ на Hyper-V будет относить к VLAN 10.

Native VLAN определяет, в какой VLAN попадает нетегированный трафик виртуальной машины.

Если NativeVlanId=10, то ВМ будет работать в VLAN10 даже без внутренней настройки VLAN.

Как подтверждение виртуальной машине с такой настройкой раздаются IP-адреса принадлежащие VLAN10. В данном описании VLAN10 назначен для сети 192.168.1.0/24.

Команда: -NativeVlanId 10 делает следующее.

Hyper-V ожидает, что внутри ВМ трафик не будет иметь VLAN-тегов. Любой нетегированный трафик для виртуальной машины Hyper-V помечает как VLAN 10, когда отправляет на внешний коммутатор. DHCP-сервер в VLAN10 получает этот трафик как будто он из VLAN10. DHCP выдаёт адрес из VLAN10. ВМ получает IP без необходимости настройки VLAN внутри себя. То есть: Native VLAN = VLAN «по умолчанию», если ВМ не разбирает VLAN-теги. Поэтому: ВМ отправляет обычные пакеты, Hyper-V делает их VLAN10 (так как native = 10), коммутатор принимает это как VLAN10, DHCP-сервер выдаёт IP из VLAN10.

Если ВМ должна получить IP из VLAN60 без настройки VLAN внутри самой ВМ, тогда задаём Native VLAN = 60.

После этого ВМ отправляет обычный untagged трафик.  Hyper-V автоматически помечает его тегом VLAN 60. Коммутатор получает этот трафик как VLAN60. DHCP в VLAN60 выдаёт IP-адрес. ВМ работает в VLAN60 без внутренней настройки VLAN.

Проверяем.

 

Чтобы ВМ работала в нужном VLAN без настройки VLAN внутри ОС, достаточно сделать этот VLAN Native при режиме Trunk. В этом случае Hyper-V сам пометит весь нетегированный трафик этим VLAN.

 

Management OS при транке

В Hyper-V Management OS (хост Windows Server) использует отдельный виртуальный адаптер, который создаётся на основе физического NIC при создании внешнего виртуального коммутатора.

В режиме Trunk если на виртуальном коммутаторе включено -AllowManagementOS $true, то для хоста создаётся виртуальный адаптер. Этот адаптер также видит VLAN, которые разрешены на виртуалном коммутаторе. Если виртуальный коммутатор в транке, адаптер Management OS получает только Native VLAN, указанное в NativeVlanId. Трафик других VLAN (AllowedVlanIdList) хост не видит, пока не настроит VLAN-тегирование внутри хоста вручную.

Адаптер vSW-SFP+ существует и работает на Management OS. Если виртуальный коммутатор настроен как Trunk и NativeVlan=10, хост получает IP из VLAN10. Другие VLAN (10,20,60) хост не видит, пока не настроить VLAN внутри OS.

В режиме Trunk для Management OS ничего не меняется, кроме того, что она видит только Native VLAN.

Чтобы Management OS видела другие VLAN на trunk, нужно в Windows Server назначить VLAN для виртуального адаптера.

В большинстве случаев для Management OS хватает Native VLAN, и её настраивать дальше не нужно.

 

Сброс настроек VLAN.

Команда возвращает виртуальный адаптер в исходное состояние по отношению к VLAN.

Режим адаптера меняется на Untagged (без VLAN-тегов). ВМ перестаёт быть в Access или Trunk. Трафик, который идёт из ВМ на виртуальный коммутатор, не маркируется VLAN.

Проверяем.

 

VLAN на физическом адаптере.

Packet Priority & VLAN – включает поддержку IEEE 802.1Q VLAN и 802.1p приоритета пакетов на физическом адаптере. Hyper-V использует это для того, чтобы VLAN-теги и приоритет трафика (QoS) могли корректно проходить через NIC.

VLAN ID – этот параметр позволяет назначить VLAN прямо на физическом адаптере. Значение 0(ноль) означает «нет VLAN», т.е. адаптер пропускает все теги VLAN и сам не добавляет тег. Если указать, например, 10, то физический NIC будет автоматически помечать весь трафик этим VLAN, независимо от Hyper-V.

В Hyper-V обычно VLAN на уровне физического NIC не трогают, чтобы Hyper-V управлял тегами через виртуальные адаптеры. Назначение VLAN на NIC может конфликтовать с VLAN на виртуальном коммутаторе или виртуальных машинах. Microsoft Hyper-V рекомендует оставить VLAN ID = 0 и управлять VLAN через виртуальный коммутатор и виртуальные адаптеры, чтобы было гибко и совместимо с Access и Trunk.

В GUI эти две настройки находятся в дополнительных свойствах физического адаптера.

Возможно, что это описание первоначально выглядит сложно, но при постоянной работе с VLAN всё это становится логично и понятно.