Как настроить сеть для виртуальной машины hyper v

Создание виртуальной сети

Вашей виртуальной машине потребуется виртуальная сеть, чтобы предоставить вашему компьютеру доступ к сети. Создание виртуальной сети — необязательный шаг. Если виртуальную машину не требуется подключать к Интернету или сети, перейдите к шагу создания виртуальной машины Windows.

Подключение виртуальных машин к Интернету

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

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

Создание виртуального коммутатора с помощью диспетчера Hyper-V

Откройте диспетчер Hyper-V. Чтобы сделать это быстро, нажмите кнопку или клавишу Windows и введите «Hyper-V Manager».
Если диспетчер Hyper-V найти не удается, это значит, что Hyper-V или средства управления Hyper-V отключены. Инструкции по включению см. в разделе Включение Hyper-V.

Выберите сервер в левой области или нажмите кнопку «Подключиться к серверу. » в правой области.

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

В разделе «Виртуальные коммутаторы» выберите пункт Создать виртуальный сетевой коммутатор.

В окне «Виртуальный коммутатор какого типа вы хотите создать?» выберите Внешний.

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

В разделе «Свойства виртуального коммутатора» назначьте ему имя, например Внешний коммутатор виртуальных машин.

В разделе «Тип подключения» убедитесь, что выбрана Внешняя сеть.

Выберите физический сетевой адаптер для связывания с новым виртуальным коммутатором. Этот сетевой адаптер физически подключен к сети.

Щелкните Применить, чтобы создать виртуальный коммутатор. На этом этапе, скорее всего, появится приведенное ниже сообщение. Щелкните Да, чтобы продолжить.

Щелкните ОК, чтобы закрыть окно диспетчера виртуальных коммутаторов.

Создание виртуального коммутатора с помощью PowerShell

Чтобы создать виртуальный коммутатор с внешним подключением с помощью PowerShell:

Используйте командлет Get-NetAdapter, чтобы получить список сетевых адаптеров, подключенных к системе Windows 10.

Выберите сетевой адаптер для использования с коммутатором Hyper-V и разместите экземпляр в переменной с именем $net.

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

Виртуальная сеть на ноутбуке

режим NAT.

Механизм преобразования сетевых адресов (NAT) предоставляет виртуальной машине доступ к сети вашего компьютера путем объединения IP-адреса главного компьютера с портом через внутренний виртуальный коммутатор Hyper-V.

У этого механизма есть ряд полезных возможностей.

1. NAT экономит IP-адреса за счет сопоставления внешнего IP-адреса и порта с гораздо большим набором внутренних IP-адресов.
2. NAT позволяет нескольким виртуальным машинам размещать приложения, которым требуются одинаковые (внутренние) порты связи, сопоставляя их с уникальными внешними портами.
3. NAT использует внутренний коммутатор. После создания внутреннего коммутатора вы можете не использовать сетевое подключение. Кроме того, за счет этого снижается нагрузка на сет компьютера.

Чтобы настроить сеть NAT и подключить ее к виртуальной машине, см. Руководство пользователя по созданию сети NAT.

Подход с использованием двух коммутаторов

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

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

Источник

Настройка виртуальных локальных сетей для Hyper-V

Виртуальные локальные сети виртуальных ( ЛС ) предлагают один из способов изолировать сетевой трафик. Виртуальные ЛС настраиваются в коммутаторах и маршрутизаторах, поддерживающих 802.1 q. Если вы настроили несколько виртуальных ЛС и хотите, чтобы между ними происходил обмен данными, необходимо настроить сетевые устройства, чтобы это разрешить.

Для настройки виртуальных ЛС потребуется следующее:

• Физический сетевой адаптер и драйвер, поддерживающие маркировку VLAN 802.1 q.
• Физический сетевой коммутатор, поддерживающий маркировку VLAN 802.1 q.

На узле вы настроите виртуальный коммутатор, чтобы разрешить сетевой трафик на порте физического коммутатора. Это для идентификаторов виртуальных ЛС, которые вы хотите использовать для внутренних целей с виртуальными машинами. Затем настройте виртуальную машину, чтобы указать виртуальную ЛС, которую виртуальная машина будет использовать для всех сетевых подключений.

Чтобы разрешить виртуальному коммутатору использовать виртуальную ЛС

Откройте — Диспетчер Hyper V.

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

В разделе виртуальные коммутаторы выберите виртуальный коммутатор, подключенный к физическому сетевому адаптеру, который поддерживает виртуальные ЛС.

В области справа в разделе идентификатор виртуальной ЛС выберите включить идентификацию виртуальной локальной сети , а затем введите номер виртуальной ЛС.

Весь трафик, проходящий через физический сетевой адаптер, подключенный к виртуальному коммутатору, будет помечен заданным ИДЕНТИФИКАТОРом виртуальной ЛС.

Чтобы разрешить виртуальной машине использовать виртуальную ЛС

Откройте — Диспетчер Hyper V.

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

В разделе оборудование выберите виртуальный коммутатор, для которого настроена виртуальная ЛС.

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

Если виртуальная машина должна использовать больше виртуальных ЛС, выполните одно из следующих действий.

Подключение несколько виртуальных сетевых адаптеров для соответствующих виртуальных коммутаторов и назначьте идентификаторы виртуальных лс. Убедитесь, что правильно настроены IP-адреса и что трафик, который нужно маршрутизировать через виртуальную ЛС, также использует правильный IP-адрес.

Настройте виртуальный сетевой адаптер в режиме магистрали с помощью командлета Set — вмнетворкадаптервлан .

Источник

Виртуализация сети в Hyper-V. Настройка

В прошлый раз я описал концепцию и общую архитектуру Hyper-V Network Virtualization (NV) – технологии Windows Server 2012, обеспечивающей виртуализацию на уровне сетевого сегмента. Сегодня речь пойдет о настройке этой технологии с помощью PowerShell и System Center 2012 SP1 Virtual Machine Manager (VMM).

Настройка Hyper-V Network Virtualization с помощью PowerShell

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

• New-NetVirtualizationLookupRecord – создает элемент в таблице политики виртуализации;
• New-NetVirtualizationProviderAddress – присваивает сетевому интерфейсу адрес провайдера (Provider Address, PA);
• New-NetVirtualizationProviderRoute – задает маршрут для маршрутизации трафика в физической сети;
• New-NetVirtualizationCustomerRoute – задает маршрут для маршрутизации трафика в виртуальных сетях.

Как обычно для PowerShell, существуют аналогичные команды с префиксами Get-, Set-, Remove- для получения текущих параметров, изменения и удаления соответственно.

Еще пара командлетов, Get-NetVirtualizationGlobal и Set-NetVirtualizationGlobal позволяют определить (и, соответственно, задать), используется ли внешний Gateway для маршрутизации трафика.

Самый простой способ познакомиться с перечисленными командлетами – изучить и попробовать применить в тестовой среде два скрипта-примера, разработанных моими коллегами. Каждый скрипт содержит детальные комментарии, описание моделируемой среды и указание на те переменные и константы, которые вам необходимо заменить на собственные значения. Найти и скачать скрипты можно здесь:

• Simple Hyper-V Network Virtualization Demo
• Simple Hyper-V Network Virtualization Script with Gateway

Проверял лично, работает. 🙂 Но, думаю очевидно, что в масштабах ЦОД-а манипуляция подобными скриптами превращается в крайне сложную задачу. Поэтому далее гораздо более детально я рассмотрю настройку NV с помощью VMM.

Настройка Hyper-V Network Virtualization с помощью System Center 2012 SP1 Virtual Machine Manager

Технология NV является частью Hyper-V в Windows Server 2012. System Center поддерживает Windows Server 2012, начиная с версии System Center 2012 SP1. Здесь и далее речь идет о VMM именно из System Center 2012 SP1. Я предполагаю, что VMM уже развернут, хосты Hyper-V в него добавлены, поэтому буду обращать внимание только на те настройки, которые непосредственно связаны с NV.

Настройка NV с помощью VMM состоит из следующих шагов:

1. Включение фильтра Windows Network Virtualization (WNV) на хостах с поднятой ролью Hyper-V.
2. Включение NV для нужных логических сетей.
3. Создание сетей виртуальных машин (VM Network) и пулов IP-адресов.
4. Создание шаблонов виртуальных машин (VM Template) с привязкой к нужным сетям виртуальных машин.
5. Развертывание ВМ с использованием подготовленных в п. 4 шаблонов.

Рассмотрим последовательно каждый шаг.

Включение фильтра Windows Network Virtualization (WNV)

Вручную
Напомню, что правила, определяющие работу NV, задаются в так называемой политике виртуализации. Определенные настройки, заданные в политике виртуализации, непосредственно к сетевым пакетам применяются драйвером-фильтром уровня NDIS (Network Driver Interface Specification), называемым Windows Network Virtualization (WNV). Этот фильтр необходимо включить на тех хостах Hyper-V, на которых планируется использовать NV. Вручную это делается в свойствах физического сетевого адаптера хоста. Подчеркиваю, именно физического адаптера, а не виртуального, который, как правило, создается при настройке внешнего свитча Hyper-V.

С помощью Logical Switch
В качестве альтернативы ручной настройке можно использовать появившийся в VMM 2012 SP1 механизм логических свитчей (Logical Switch). Более подробное описание настроек сети в VMM можно найти вот в этом посте Георгия Гаджиева. Здесь же кратко упомяну, что логический свитч необходим для того, чтобы применить заданный набор настроек к сетевым адаптерам и свитчам Hyper-V Extensible Switch на множестве хостов. Найти описанные ниже настройки можно в разделе «Fabric», подразделе «Networking» консоли VMM. Фактически в логическом свитче можно задать три группы настроек: настройки для физических сетевых адаптеров хостов, настройки для виртуальных сетевых адаптеров ВМ (а точнее, для портов Hyper-V Extensible Switch, к которым ВМ подключаются) и настройки для расширений (extensions) Hyper-V Extensible Switch.

Первая группа настроек, а именно она нас больше всего интересует, задается путем создания специального профиля, который называется Uplink Port Profile. В профиле необходимо установить чекбокс, показанный на рисунке, благодаря которому и будет в дальнейшем включен фильтр WNV.

Вторая группа настроек задается путем создания профиля, который называется Virtual Adapter Port Profile. В этом профиле нет настроек, напрямую связанных с NV, но именно там можно задать различные параметры безопасности свитча (например, DHCP Guard), производительности (например, IP Sec offload), ограничения трафика (Quality of Service).

Ну а далее при создании логического свитча можно указать необходимые расширения для Hyper-V Extensible Switch, выбрать Virtual Adapter Port Profile и, самое главное, добавить Uplink Port Profile, в котором мы пометили чекбокс «Enable Windows Network Virtualization».

Тем самым, мы создали некоторый набор настроек в виде логического свитча. Остается применить созданный логический свитч к требуемым хостам Hyper-V, а как следствие, применятся к хостам и все настройки этого логического свитча. Для этого в консоли VMM в свойствах хоста переходим на закладку Virtual Switches, нажимаем «New Virtual Switch», затем «New Logical Switch» и выбираем нужный логический свитч. Проверяем, что для требуемого физического сетевого адаптера применяется тот самый Uplink Port Profile.

Включение NV для логических сетей

Следующий шаг – включение NV для требуемых логических сетей (Logical Networks). Логические сети в VMM позволяют администратору описать физическую сетевую топологию ЦОД-а. Это описание в дальнейшем помогает существенно упростить подключение ВМ к требуемым сетевым сегментам. Похожим образом администратор Active Directory (AD) с помощью сайтов и подсетей описывает физическую сеть предприятия для оптимизации трафика репликации AD. Применительно же к NV логические сети VMM не просто описывают реальную сетевую топологию, но и определяют пространство PA-адресов, которые будут использоваться для передачи пакетов между ВМ на разных хостах.

Итак, представим себе, что в физической сети используется IP-адресация из диапазона 192.168.1.0/24. Нам же необходимо поверх этой сети виртуализовать сети двух компаний ОАО «Синие» и ОАО «Красные». Причем обе компании используют одинаковый диапазон IP-адресов, а именно: 10.0.0.0/24.

Создаем логическую сеть (кнопка меню «Create Logical Network») и на первом же экране разрешаем для этой сети NV:

На следующем экране создаем сайт и указываем, какие группы хостов могут этот сайт использовать (фактически в нем располагаются) и какие IP-подсети этому сайту принадлежат.

Теперь для этой логической сети необходимо создать пул IP-адресов. В контексте NV именно из этого пула VMM будет выделять PA-адрес и ассоциировать с ВМ и настроенными внутри них CA-адресами. В консоли VMM нажимаем «Create IP Pool», задаем имя пула и на следующем экране указываем для какого сайта и какой IP-подсети создаем пул.

Затем необходимо задать диапазон IP-адресов и, если требуется, какие-то адреса зарезервировать. Например так:

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

Создание сетей виртуальных машин (VM Network) и пулов IP-адресов

На предыдущих шагах мы включили фильтр WNV и настроили логическую сеть с пулом IP-адресов, который будет использоваться для выделения PA-адресов. Таким образом, мы подготовили физическую инфраструктуру или, в терминологии VMM, подготовили Fabric. Теперь поверх этой инфраструктуры можно создавать и виртуализовывать произвольные сети клиентов нашего ЦОД-а. В рассматриваемом сценарии этими клиентами, как вы помните, являются компаний ОАО «Синие» и ОАО «Красные», использующие одинаковую подсеть 10.0.0.0/24.

С выходом SP1 для System Center 2012 в VMM появился новый тип объектов – сеть виртуальных машин (VM Network), далее просто «сеть ВМ». В первую очередь, этот тип объектов предназначен для NV, хотя, как вы увидите в дальнейшем, даже если NV не используется, как минимум одну сеть ВМ создать необходимо. Ну а в нашем случае, очевидно, нужно создать две сети ВМ для «Синих» и «Красных» соответственно. Процесс этот очень похож на создание логической сети – мы создаем сеть ВМ, определяем в ней один или несколько сайтов с указанием подсетей, затем создаем для подсетей пулы IP-адресов. Но эти пулы уже будут использоваться для выделения CA-адресов виртуальным машинам.

Итак, в консоли VMM переходим в раздел «VMs and Services» и нажимаем кнопку «Create VM Network». В первом окне задаем имя создаваемой сети и выбираем из списка логическую сеть, поверх которой будет работать данная сеть ВМ.

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

Но здесь же хотел бы обратить ваше внимание на вторую опцию «No Isolation». Если выберем ее, то укажем тем самым VMM, что виртуальные машины этой сети должны напрямую (без изоляции) подключаться к логической сети. Никаких дополнительных настроек в этом случае уже не потребуется. Создаваемые затем ВМ буду получать IP-адреса из пулов, настроенных непосредственно в логической сети. То есть опцию «No Isolation» вы выбираете в том случае, когда технология NV вам не нужна. И поэтому закономерно, что для каждой логической сети можно создать только одну сеть ВМ без изоляции.

Мы же двигаемся дальше и в следующем окне создаем подсеть (одну или несколько), которая требуется клиенту.

На завершающем экране мастера выбираем способ взаимодействия ВМ создаваемой сети с внешним миром. Поскольку мы не настраивали специально внешний шлюз (об этом речь пойдет в следующем посте), то выбор здесь один – «No Connectivity», означающий, что ВМ смогут взаимодействовать только в пределах этой сети ВМ.

Последняя задача данного этапа – настроить для созданной сети ВМ пулы адресов, то есть CA-адреса. В консоли VMM выбираем сеть ВМ и нажимаем «Create IP Pool». На первом экране проверяем, что указаны нужные сеть ВМ и подсеть:

На втором задаем диапазон IP-адресов для ВМ:

Указываем шлюз по умолчанию:

При необходимости задаем далее адреса серверов DNS и WINS. Сеть «Красных» настроена. Повторяем процедуру для ОАО «Синие» и в результате получаем вот такую картину:

Настройка собственно виртуализации сети на этом завершена. Если вспомнить концепцию и архитектуру NV, описанные мною в предыдущем посте, то становится понятно, что VM Network соответствует термину Customer Network, а VM Subnet – термину Virtual Subnet. Действительно, если с помощью командлетов Get-SCVMNetwork и Get-SCVMSubnet получить информацию о созданных только что нами объектах, то в отклике первого командлета среди прочего вы увидите Routing Domain ID (RDID), а второго – Virtual Subnet ID (VSID).

Остается создать шаблоны ВМ для каждой сети, и на их основе можно будет развертывать требуемое количество «Синих» и «Красных» ВМ.

Создание шаблонов виртуальных машин (VM Template)

Процедура создания шаблонов для ВМ, которые будут использовать NV, совершенно стандартная и по сути ничем не отличается от создания шаблонов для любых других ВМ. Единственное, на что надо обратить внимание, что виртуальный сетевой адаптер подключен к нужной сети ВМ. Например, для шаблона «Красных» эта настройка выглядит следующим образом:

Параметр «Static IP» указывает VMM на то, что при создании ВМ по этому шаблону необходимо выделить статический IP-адрес из пула, связанного с сетью Red_VMnet01. А поскольку для этой сети включена технология NV, то выделенный адрес будет CA-адресом. Кроме того, в процессе развертывания виртуальной машины VMM выделит из пула, связанного с соответствующей логической сетью, PA-адрес, ассоциирует пару CA-адрес / PA-адрес и пропишет необходимые строчки в политику виртуализации того хоста, на котором будет развернута ВМ. Если в ЦОД-е используется динамическая адресация, то IP-адреса могут выделяться не из пулов VMM, а из скопов DHCP-сервера, и в этом случае в шаблоне ВМ необходимо выбрать параметр «Dynamic IP».

Развертывание ВМ с использованием подготовленных шаблонов

Теперь все полностью готово, и можно разворачивать ВМ на основе подготовленных шаблонов. Нажимаем кнопку «Create Virtual Machine» и выбираем нужный шаблон.

Проверка результатов

Если все перечисленные шаги проделаны без ошибок, то для эксперимента можно создать пару «Красных» и пару «Синих» ВМ на одном или нескольких физических хостах Hyper-V и убедиться в том, что полученные ВМ работают с адресами из сети 10.0.0.0/24, возможно даже IP-адреса «Синих» и «Красных» полностью совпадают, но при всем при этом «Красные» видят друг друга и полностью изолированы от «Синих».

Давайте посмотрим, как выглядит отклик одного из упомянутых в начале поста командлетов в моей тестовой среде. Ниже фактически изображена политика виртуализации на одном из хостов:

В частности видно, что машине Red-Web1 был выделен CA-адрес 10.0.0.2 (первый доступный адрес в пуле) и ассоциирован с PA-адресом 192.168.1.52. ВМ принадлежит подсети с VSID=15184632 и относится к Customer Network с идентификатором RDID=<206146eb-f035-4a19-a625-054c49deebd7>.

Еще один очень интересный параметр «Rule» со значением «TranslationMethodEncap» говорит о том, что для виртуализации IP-адресов используется механизм NVGRE. Этот механизм применяется по умолчанию при настройке NV в VMM и рекомендуется для большинства сценариев виртуализации сети. Можно проверить работу механизма инкапсуляции, сделав c машины Red-Web1 ping на адрес 10.0.0.3 и посмотрев сетевым монитором на структуру передаваемых пакетов.

Во-первых, можно наблюдать, что пинги передаются в виде GRE-пакетов между хостами с PA-адресами 192.168.1.52 и 192.168.1.53. Во-вторых, в заголовке GRE указано, что внутри лежит пакет некоторого протокола с номером 0x6558 (выделен на рисунке синим), каковым и является стандарт NVGRE. В-третьих, по спецификации NVGRE следующие 24 бита (обведены красным) содержат VSID. Действительно, если 0xE7B2F8 перевести в десятичный вид, получим VSID=15184632, что является подсетью «Красных».

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

А пока вы можете:

• посмотреть виртуализацию сети в действии в первом модуле курса «Новые возможности Windows Server 2012. Часть 1. Виртуализация, сети, хранилища»;
• получить дополнительную информацию о Hyper-V Network Virtualization в третьем модуле курса «Windows Server 2012: сетевая инфраструктура»;
• скачать оригинальную презентацию (на англ.) с детальным описанием процесса передачи пакетов (packet flow) в NV.

Источник