В предыдущей статье, посвященной виртуализации сетей, мы затронули некоторые теоретические аспекты этого метода объединения сетевых ресурсов компьютеров в единые платформы. Поговорим теперь подробнее о некоторых нюансах виртуализации сети на примере Hyper-V – инструмента аппаратной виртуализации для 64-разрядных систем на основе гипервизора (монитора виртуальных машин) – в Windows Server 2016.
Виртуализация сети Microsoft Hyper-V позволяет нескольким виртуальным сетям (потенциально с перекрывающимися IP-адресами) работать в одной и той же физической сетевой инфраструктуре, благодаря чему каждая виртуальная сеть работает таким образом, будто она является единственной виртуальной сетью.
В виртуализации сети Hyper-V (HNV) пользователь или клиент определяется как «владелец» набора IP-подсетей, развернутых в организации. В качестве клиента может выступать организация или предприятие с несколькими подразделениями, нуждающимися в изоляция сети. Каждый клиент может иметь одну или несколько виртуальных, а каждая виртуальная сеть включать в себя несколько виртуальных подсетей. Виртуальной сетью создается граница изоляции, внутри которой виртуальные машины в виртуальной сети получают возможность для взаимодействия друг с другом. Традиционно такая изоляция применяется при помощи виртуальных локальных сетей с разделенным диапазоном IP-адресов и 802.1-ым тегом q или идентификатором виртуальной локальной сети. Однако в случае использовании HNV для изоляции применяется метод инкапсуляции NVGRE или режим VKSLAN, необходимый для создания сетей наложения с возможностью перекрытия IP-подсетей между клиентами.
У каждой виртуальной сети есть свой уникальный идентификатор домена маршрутизации на узле. Этот идентификатор приблизительно соответствует идентификатору ресурса, необходимому для установления контакта с ресурсом RESTFUL виртуальной сети в сетевом контроллере. Для указания ссылки на ресурс RESTFUL виртуальной сети используются имена универсального кода ресурса (URI), к которому добавляется идентификатор этого ресурса.
Виртуальная подсеть отвечает за реализацию семантики подсети IP третьего уровня для виртуальных машин одной виртуальной подсети. После чего этой сетью образуется широковещательный домен, (аналогичный виртуальной локальной сети) обеспечивающий строгую изоляцию за счет использования поля идентификатора клиента NVGRE (ТНИ) или идентификатора VKSLAN сети. Каждая виртуальная подсеть относится к одной виртуальной сети и ей назначается уникальный идентификатор виртуальной подсети (VSID), который использует особый ключ в заголовке инкапсулированного пакета. Здесь важно, чтобы VSID отвечал требованиям уникальности и находится в диапазоне от 4096 до 2^24–2. Решающим преимуществом виртуальной сети и домена маршрутизации является то, что он дает клиентам возможность использовать собственные топологии сети (например, IP-подсети) в облаке.
Скажем несколько слов и об архитектуре виртуализации сетей Hyper-V. В Windows Server 2016 HNVv2 осуществляется при помощи виртуальной платформы фильтрации Virtual Filtering Platform Azure (VFP), являющейся расширением фильтрации NDIS в коммутаторе Hyper-V. Ключевым принципом работы VFP является то, что подсистема обработки тождеств с внутренним интерфейсом API предоставляется агенту узла SDN для программирования сетевой политики. Самому агенту узла SDN информация о сетевой политике приходит сетевого контроллера по каналам связи Open vSwitch Database Management Protocol (OVSDB) и Windows Communication Foundation (WCF).
Важно отметить, что с помощью VFP программируется не только политика виртуальной сети (например, сопоставление CA-PA) запрограммированная с помощью VFP, но и дополнительной политики, такой как ACL, QoS. В VFP создается слой для каждого типа политики (например, виртуальная сеть), являющийся эксклюзивным набором таблиц правил или потоков. Эта политика лишена каких-либо встроенных функций до тех пор, пока для их реализации не назначаются определенные правила. Каждый слой получает приоритет, после чего уровни назначаются порту согласно возрастанию их приоритета. Правила организуются в группы по большей части соответствуя направлениям и семействам IP-адресов. Группы также получают свой приоритет таким образом, чтобы одно правило группы соответствовало одному заданному потоку.
Подытоживая необходимо подчеркнуть, что технологии виртуализации сетей на основе технологии облака могут обеспечивать использующей их компании множество преимуществ, например улучшенную масштабируемость и более эффективное использование ресурсов. Для реализации этих потенциальных преимуществ требуется использование технологии, которая посвящена решению проблем многоклиентской масштабируемости в динамической среде. И в этом плане виртуализация сети Hyper-V – интересный пример решения этих проблем с помощью разграничения топологий физической и виртуальной сетей.
Время на прочтение
5 мин
Количество просмотров 36K
Hyper-V Extensible Switch – ключевая компонента Hyper-V в Windows Server 2012 – представляет собой расширяемый управляемый коммутатор второго уровня. Расширяемость означает возможность создания разработчиками модулей, встраиваемых в Hyper-V и модифицирующих/расширяющих штатный функционал анализа, фильтрации и форвардинга пакетов. Управляемость подразумевает наличие целого набора настроек, доступных администратору через PowerShell или консоль Hyper-V Manager, обеспечивающих требуемый уровень изоляции, безопасности и мониторинга запущенных виртуальных машин (ВМ). В одном из предыдущих постов я описывал реализацию технологии Private VLAN (PVLAN) в Hyper-V Extensible Switch. Сегодня посмотрим на ряд дополнительных возможностей.
С точки зрения терминологии понятие Hyper-V Switch (или Virtual Switch) пришло на смену понятию виртуальной сети (Virtual Network) в Windows Server 2008/2008 R2. Если раньше, чтобы обеспечить взаимодействие ВМ между собой или с внешним миром, вы создавали виртуальную сеть одного из трех типов – External, Internal, Private – то теперь вы создаете Virtual Switch, который может быть тех же трех типов и обладает всеми возможностями, описанными ниже. Причем эти возможности задаются для конкретного порта виртуального свича (см. рис.), а порт, в свою очередь, идентифицируется именем виртуальной машины, которая к этому порту подключена, точнее, именем виртуального сетевого адаптера, поскольку таких адаптеров у ВМ может быть несколько.
Далее рассматриваемые настройки Hyper-V Extensible Switch я разбил на три категории: безопасность и изоляция, мониторинг, отказоустойчивость.
Безопасность и изоляция
В консоли Hyper-V Manager в свойствах виртуального сетевого адаптера появился новый подраздел Advanced Features. Первые три настройки в этом окне непосредственно связаны с безопасностью и изоляцией.
Спуфинг MAC-адреса (MAC address spoofing)
По умолчанию Hyper-V запрещает спуфинг МАС-адреса. Иными словами, если ВМ пытается в исходящих пакетах заменить МАС-адрес отправителя, то есть свой МАС-адрес, ассоциированный с виртуальным сетевым адаптером этой машины, на другой МАС-адрес, Hyper-V блокирует такие пакеты. Установка верхнего чекбокса, соответственно, спуфинг разрешает. Как всегда, все, что можно сделать в консоли Hyper-V Manager и даже больше, можно сделать в PowerShell. Для приведенной на рисунке ВМ с именем SRV4 включение спуфинга MAC-адреса реализуется следующей командой:
Set-VMNetworkAdapter -VMName srv4 -MacAddressSpoofing OnЗащита DHCP (DHCP Guard)
Данную настройку необходимо использовать для блокировки неавторизованного сервера DHCP, запущенного внутри ВМ. Технически при установке данного чекбокса Hyper-V блокирует пакеты DHCP acknowledge от данной ВМ и предотвращает возможность получения DHCP-клиентами настроек IP от данной ВМ.
Set-VMNetworkAdapter -VMName srv4 -DhcpGuard OnЗащита маршрутизатора (Router Guard)
По аналогии с DHCP Guard установка этого чекбокса блокирует пакеты редиректа и объявления маршрутизатора (redirection и router advertisement) от данной ВМ. Тем самым ВМ не сможет повлиять на таблицы маршрутизации других компьютеров сети.
Set-VMNetworkAdapter -VMName srv4 -RouterGuard OnСписок управления доступом порта (Port Access Control List, Port ACL)
Для каждого порта Hyper-V Extensible Switch вы можете настроить один или несколько списков управления доступом (ACLs), чтобы задать дополнительные правила безопасности и уровень изоляции ВМ. Все настройки ACL задаются только через PowerShell, в консоли Hyper-V Manager управление списками недоступно. Просмотреть текущее состояние списков можно командой:
Get-VMNetworkAdapterAcl -VMName srv4Добавление и удаление списка выполняется командами Add-VMNetworkAdapterAcl и Remove-VMNetworkAdapterAcl соответственно. Синтаксис обеих команд одинаков. Для каждого списка ACL необходимо указать:
- Локальный или удаленный IP-адрес или MAC-адрес
- Направление действия: входящий трафик, исходящий трафик, оба направления (Inbound, Outbound, Both)
- Собственно действие: разрешить, запретить, измерить (Allow, Deny, Meter)
По умолчанию, никакие ACLs не заданы, и, таким образом, разрешен любой трафик. Пример ниже запрещает для ВМ с именем SRV4 любой трафик с/на IP-адрес 192.168.1.143:
Add-VMNetworkAdapterAcl -VMName srv4 -RemoteIPAddress 192.168.1.143 -Direction Both -Action DenyПрименительно к IP-адресам можно указывать не только конкретный адрес, но и подсеть:
Add-VMNetworkAdapterAcl -VMName srv4 -RemoteIPAddress 192.168.1.0/24 -Direction Both -Action DenyЕсли заданы ACLs и для подсети, и для конкретного адреса из этой подсети, то ACL для адреса имеет больший приоритет, то есть «более конкретное» правило имеет большую силу. Например, ниже показан результат выполнения команды Get-VMNetworkAdapterAcl:
Как видно, задан запрет на подсеть 192.168.1.0/24, и при этом разрешен трафик для адреса 192.168.1.143. В результате, IP-трафик возможен только на один 143-й адрес из всей подсети.
Действие Meter позволяет измерять объем входящего и/или исходящего трафика для указанного IP- или MAC-адреса с момента создания соответствующего ACL, например, следующая команда включает измерение входящего трафика с адреса 192.168.1.143:
Add-VMNetworkAdapterAcl -VMName srv4 -RemoteIPAddress 192.168.1.143 -Direction Inbound -Action MeterРезультат можно увидеть с помощью все той же Get-VMNetworkAdapterAcl:
Мониторинг
Мониторинг трафика можно реализовать благодаря механизму зеркалирования порта (port mirroring). Для настройки зеркалирования необходимо указать источник информации, в Hyper-V Manager это делается здесь:
И затем в настройках нужной ВМ, которая и будет осуществлять мониторинг трафика, выбрать в таком же поле значение Destination. В PowerShell это делается параметрами команды Set-VMNetworkAdapter:
Set-VMNetworkAdapter -VMName srv4 -PortMirroring DestinationПосле чего весь трафик, входящий и исходящий, на порт ВМ SRV3 копируется и перенаправляется на порт ВМ SRV4. Останется только установить в SRV4 необходимое ПО для анализа трафика. Важное условие, обе ВМ должны быть подключены к одному виртуальному свичу.
Отказоустойчивость
Последняя опция в расширенных свойствах виртуального сетевого адаптера относится к отказоустойчивости, а именно к технологии группирования сетевых адаптеров (NIC Teaming).
NIC Teaming – штатная возможность Windows Server 2012, заслуживающая, вообще говоря, отдельного поста. Эта возможность позволяет объединить несколько физических сетевых адаптеров в группу и обеспечить, с одной стороны, отказоустойчивость сетевого трафика при выходе какой-либо «сетевушки» из строя, с другой стороны, агрегирование пропускной способности адаптеров, включенных в группу.
По разным причинам вы можете не захотеть включать тиминг на хостовой машине. Тем не менее, если на хосте более одного физического сетевого адаптера, можно использовать NIC Teaming внутри гостевой ОС. Представим, что на хосте две сетевые карточки. Если в некоторой ВМ два виртуальных сетевых адаптера, эти адаптеры через два виртуальных свича типа external подключены к, соответственно, двум физическим карточкам, и внутри ВМ установлена ОС Windows Server 2012, то вы можете сконфигурировать NIC Teaming внутри гостевой ОС. И такая ВМ сможет воспользоваться всеми преимуществами тиминга, и отказоустойчивостью, и повышенной пропускной способностью. Но для того, чтобы Hyper-V понимал, что при выходе из строя одного физического адаптера, трафик для этой ВМ нужно перебросить на другой физический адаптер, как раз и нужно установить упомянутый чекбокс в свойствах каждого виртуального NIC, входящего в тиминг. В PowerShell аналогичная настройка задается следующим образом:
Set-VMNetworkAdapter -VMName srv4 -AllowTeaming OnВсе рассмотренные выше настройки могут быть заданы для запущенных ВМ и вступают в силу немедленно. Разумеется, это не весь функционал Hyper-V Extensible Switch. Просмотрев перечень доступных в Hyper-V командлетов, вы сможете найти еще много интересного.
В заключении хочу заметить, что 26 ноября в Москве пройдет бесплатный семинар из серии IT Camp, посвященный Windows Server 2012 и System Center 2012. Семинар будут проводить мои коллеги – Георгий Гаджиев и Саймон Перриман (Редмонд). Вы сможете посмотреть на продукты живьем и задать возникшие вопросы.
Надеюсь, материал был полезен.
Спасибо!
Windows Server 2012 и Hyper-V — фундаментальные строительные блоки частного «облака» Microsoft. Вместе с новейшей серверной операционной системой Microsoft поставляется гипервизор Hyper-V 3.0, в котором произошли многочисленные изменения. Hyper-V 3.0 может стать первой платформой виртуализации Microsoft, по своим достоинствам вполне сопоставимой с VMware vSphere
Windows Server 2012 и Hyper-V — фундаментальные строительные блоки частного «облака» Microsoft. Вместе с новейшей серверной операционной системой Microsoft поставляется гипервизор Hyper-V 3.0, в котором произошли многочисленные изменения. Hyper-V 3.0 может стать первой платформой виртуализации Microsoft, по своим достоинствам вполне сопоставимой с VMware vSphere.
Среди изменений Hyper-V — несколько новых функций, направленных на повышение безопасности. Виртуализация сети Network Virtualization — первый шаг Microsoft к централизованно программируемым сетям Software-Defined Networking (SDN). В SDN управление сетевым трафиком возлагается на программы, исполняемые не на физическом оборудовании сети. В результате мы получаем более гибкое управление и точную настройку сети. С точки зрения безопасности, благодаря SDN и виртуализации сети компании и поставщики услуг «облака» могут надежнее изолировать виртуальные машины на сетевом уровне.
В Hyper-V 3.0 также реализовано множество мелких, но не менее важных изменений, относящихся к безопасности. Например, это расширяемый коммутатор виртуальной сети, новая группа администраторов Hyper-V и усовершенствованное шифрование дисков BitLocker.
Определение виртуализации сети
Благодаря виртуализации сети возможности изолирования виртуальных машин расширяются с узла на сетевой уровень. Изоляция — необходимое условие многоабонентских «облачных» решений, в которых приложения и службы различных компаний или подразделений размещаются в одном физическом сервере и сетевой инфраструктуре. Например, поставщик «облака», который размещает службы для компаний Apple и Samsung, наверняка не заинтересован в том, чтобы сотрудники Apple заглядывали в виртуальные машины и сеть Samsung, и наоборот.
Подобно тому, как виртуализация сервера дает возможность установить несколько изолированных виртуальных машин на одном узле, виртуализация сети Hyper-V 3.0 позволяет запускать несколько изолированных виртуальных сетей в одной физической сети. В виртуализации сети задействован программный уровень абстракции, расположенный поверх физической сети и основанный на концепции виртуальных подсетей. Виртуальная подсеть образует границу широковещательной передачи пакетов, и только виртуальные машины в одной виртуальной подсети могут устанавливать связь друг с другом. Таким образом, с помощью виртуальных подсетей администраторы могут организовать различные изолированные домены широковещательной передачи между виртуальными машинами.
Hyper-V поддерживает использование виртуальных локальных сетей VLAN для создания изолированных виртуальных сетей с момента выхода Windows Server 2008, но масштабируемость и гибкость виртуальных локальных сетей ограничены. Виртуальные локальные сети поддерживают лишь определенное число изолированных сетей клиентов. Основная причина в том, что коммутаторы, как правило, поддерживают не более 1000 идентификаторов VLAN из теоретического максимума 4096. По данным Microsoft, виртуализация сети обеспечивает функционирование более 16 млн виртуальных сетей.
Кроме того, виртуальным локальным сетям не хватает гибкости. Они плохо приспособлены для динамической «облачной» среды, в которой виртуальные машины клиентов регулярно появляются и исчезают в центре обработки данных и перемещаются между физическими серверами в целях балансировки нагрузки и управления вычислительными ресурсами. Управление VLAN отличается сложностью и требует изменения конфигурации на уровне коммутатора при перемещениях виртуальных машин на другой уровень. Операционная система Server 2012 также совместима с частными виртуальными локальными сетями PVLAN благодаря расширению на уровне виртуального коммутатора Hyper-V. PVLAN увеличивают уровень изоляции между виртуальными машинами, но не решают проблему сложности управления VLAN на виртуальных и физических сетевых устройствах. С этой проблемой можно справиться только с помощью виртуализации сетей.
Внутренний механизм виртуализации сетей
Для виртуализации сети каждой виртуальной машине назначается два IP-адреса. Один IP-адрес видим для виртуальных машин и имеет значение только в контексте данной виртуальной или централизованно программируемой сети клиентов. Этот адрес называется адресом клиента Customer Address (CA). Второй IP-адрес имеет значение только в контексте физической сети. Этот адрес называется адресом поставщика Provider Address (PA). Разделение на CA и PA приносит ряд преимуществ.
Прежде всего, это позволяет переносить виртуальные машины между центрами обработки данных. Благодаря новому уровню абстракции можно переместить виртуальные машины в центр обработки данных другого поставщика «облачных» услуг без изменения IP-адреса виртуальных машин или конфигурации сети и всех основанных на IP-адресе политик внутри компании. Кроме того, более не нужно беспокоиться о конфигурации IP-адресов виртуальных машин других клиентов, размещенных в том же центре обработки данных. При включенной виртуализации сети виртуальные машины с одинаковыми IP-адресами могут сосуществовать на одном узле Hyper-V и даже в одной сети без конфликтов IP-адресов.
Виртуализация сети также обеспечивает динамическую миграцию виртуальных машин между физическими серверами в различных подсетях без перерывов в обслуживании. Если у виртуальных машин два IP-адреса, то можно изменить PA, не затрагивая CA. Пользователь или приложение, установившие связь с виртуальной машиной с использованием CA, не столкнутся с перебоями соединения и не заметят физического перемещения виртуальных машин в другую подсеть.
Помимо адресов CA и PA, при виртуализации сети используется третий важный компонент: идентификатор виртуальной подсети VSID. Каждая виртуальная подсеть при виртуализации сети уникально идентифицируется посредством VSID. С помощью идентификаторов VSID узлы Hyper-V отмечают трафик из различных виртуальных подсетей соответствующими тегами и различают трафик виртуальных машин с одинаковыми CA. Программная логика виртуализации сети инкапсулирует VSID, CA и PA в каждый сетевой пакет.
Чтобы распространить конкретные сети клиентов на несколько виртуальных подсетей (и таким образом IP-подсетей), идентификаторы VSID можно сгруппировать в одну сеть клиентов, которая уникально идентифицируется с использованием идентификатора домена маршрутизации RDID. В этих ситуациях изоляция виртуализации сети будет применяться на уровне определенных сетей клиентов. В этом еще одно отличие между виртуальными сетями Network Virtualization и традиционными VLAN: сети VLAN могут быть связаны только с одной IP-подсетью.
Виртуализация сети требует только узла Hyper-V Server 2012. При виртуализации сети гостевой операционной системе в виртуальной машине неизвестно, что ее IP-адрес виртуализован. С точки зрения виртуальных машин все связи устанавливаются с использованием CA. Это также означает, что виртуальная машина, которая является частью сети на основе Network Virtualization, может работать с любой операционной системой: не только Windows 8 и Server 2012, но и более старыми версиями Windows и других операционных систем.
На экране 1 показаны принципы организации виртуализации сети. В сущности, виртуализация сети реализуется как новый сетевой драйвер (ms_netwnv), который может быть привязан к физическим сетевым адаптерам на каждом физическом сервере и виртуальном сервере Server 2012. Новый виртуальный коммутатор Hyper-V, к которому мы еще вернемся в данной статье, вызывает этот сетевой драйвер для инкапсуляции и деинкапсуляции сетевых пакетов при сетевой виртуализации.
 |
| Экран 1. Реализация виртуализации сети в качестве драйвера сетевого фильтра |
Транспортировка и маршрутизация при виртуализации сети
Для транспортировки и маршрутизации IP-пакетов с виртуализованными адресами CA через физическую сеть могут использоваться два механизма. В основе первого из них лежит протокол туннелирования Generic Routing Encapsulation (GRE), определенный в документах RFC 2784 и 2890. В этом контексте GRE используется для инкапсуляции сетевых пакетов, формируемых виртуальной машиной (с адресом CA), в пакеты, формируемые узлом (с адресом PA). Совместно с другими компаниями, занимающимися «облачными» технологиями (HP, Intel, Emulex, Dell и другими), Microsoft представила в комитет IETF проект, цель которого — сделать стандартом разновидность GRE для Network Virtualization (под названием NVGRE).
Второй механизм, переопределение IP-адреса, можно сравнить с преобразованием сетевых адресов Network Address Translation (NAT). Этот механизм переопределяет пакеты с виртуализованными адресами CA в пакеты с PA, которые можно маршрутизировать по физической сети.
На момент подготовки данной статьи переопределение IP-адреса больше подходит для виртуальных машин с высокими требованиями к пропускной способности (10 Гбит/с) благодаря использованию механизмов разгрузки сетевого адаптера на аппаратном уровне, таких как разгрузка больших пакетов large send offload (LSO) и очередь виртуальных машин virtual machine queue (VMQ). Существенный недостаток переопределения IP-адреса заключается в необходимости одного уникального PA для каждого CA виртуальной машины. В противном случае было бы невозможно распознавать и маршрутизировать сетевые пакеты, исходящие и поступающие в виртуальные машины разных клиентов с перекрывающимися IP-адресами.
Для GRE требуется только один PA на узел, поэтому Microsoft рекомендует использовать NVGRE при переопределении IP-адресов для виртуализации сети. NVGRE можно реализовать, не внося изменений в архитектуру физического сетевого коммутатора. Туннели NVGRE завершаются на узлах Hyper-V и выполняют всю инкапсуляюцию и деинкапсуляюцию сетевого трафика GRE.
Недостаток GRE состоит в невозможности задействовать механизмы разгрузки сетевого адаптера на аппаратном уровне. Поэтому, если вы планирует использовать NVGRE для виртуализации сети с высокой пропускной способностью, рекомендуется подождать выпуска сетевых адаптеров с функцией разгрузки NVGRE. Microsoft ожидает, что такие платы для Server 2012 появятся в продаже в 2013 году. При использовании GRE не забудьте о брандмауэрах, в которых по умолчанию могут быть заданы правила для блокирования GRE. Всегда проверяйте, разрешен ли туннельный трафик GRE (IP Protocol 47) в брандмауэре.
Реализация Network Virtualization
Процесс реализации и настройки Network Virtualization в Hyper-V 3.0 отличается от настройки частных локальных сетей в Hyper-V. Частные локальные сети можно настроить из диспетчера Hyper-V в настройках сетевого адаптера виртуальных машин. Настройка виртуализации сети не является частью настройки виртуальных машин и не может быть выполнена из диспетчера Hyper-V. Это объясняется тем, что виртуализация сети основывается на определенных политиках, применяемых на уровне виртуального коммутатора узла Hyper-V.
Чтобы определить политики виртуализации сети локально на узле, необходимо использовать сценарии Windows PowerShell. Для централизованного определения политик можно задействовать графический интерфейс диспетчера Microsoft System Center Virtual Machine Manager (VMM) с пакетом обновления 1 (SP1). VMM — унифицированное решение Microsoft для управления виртуальными машинами. В крупной среде Network Virtualization настоятельно рекомендуется использовать VMM. VMM может запускать нужные команды PowerShell от имени пользователя и применять политики виртуализации сети на узле Hyper-V через локальные агенты узла System Center. Важное ограничение, существующее на данный момент, заключается в том, что графический интерфейс VMM можно использовать только для задания политик переопределения IP-адресов. Чтобы назначить политики NVGRE, необходимо задействовать сценарии PowerShell. Начинающие пользователи могут освоить приемы настройки Network Virtualization через PowerShell с помощью примера сценария на PowerShell в демонстрационном пакете Simple Hyper-V Network Virtualization Demo, подготовленном компанией Microsoft (http://gallery.technet.microsoft.com/scriptcenter/Simple-Hyper-V-Network-d3efb3b8).
Приступая к работе с NVGRE, следует также предусмотреть функции шлюза Network Virtualization. Шлюз Network Virtualization необходим для того, чтобы обеспечить связь виртуальных машин в виртуальной сети с компьютерами вне виртуальной сети. Шлюз Network Virtualization распознает политики сопоставления адресов при виртуализации сети. Он может преобразовать сетевые пакеты, инкапсулированные в NVGRE, в некапсулированные пакеты, и наоборот.
Шлюзы Network Virtualization поставляются в различных конструктивных вариантах. Они могут быть построены на шлюзе VPN, который формирует VPN-соединение, чтобы связать две виртуальные сети через физическую сеть. Для этой цели можно использовать сервер Server 2012, на котором выполняется служба маршрутизации RRAS. Функциональность шлюза Network Virtualization может быть предоставлена и выделенным сетевым устройствам (например, коммутаторам, сетевым устройствам), которые действуют как шлюз маршрутизации для виртуализации сети. На данный момент шлюзовые устройства Network Virtualization выпускаются или готовятся к выпуску компаниями F5 Networks и nAppliance Networks. Настроить шлюзы Network Virtualization можно с помощью PowerShell. Начинающим полезно познакомиться с примером сценария в статье Microsoft «Simple Hyper-V Network Virtualization Script with Gateway» (http://gallery.technet.microsoft.com/scriptcenter/Simple-Hyper-V-Network-6928e91b).
К счастью, существуют расширения VMM SP1 для централизованного и автоматического управления политиками шлюза Network Virtualization. При создании или обновлении виртуальной машины VMM может автоматически обновить топологию маршрутизации каждого устройства шлюза Network Virtualization. Дополнительные сведения о шлюзах Network Virtualization можно найти в статье Microsoft «Hyper-V Network Virtualization Gateway Architectural Guide» (http://technet.microsoft.com/en-us/library/jj618319.aspx).
Гораздо более подробная общая информация о виртуализации сети приведена в статье Microsoft «Microsoft Windows Server 2012 Hyper-V Network Virtualization Survival Guide» (http://social.technet.microsoft.com/wiki/contents/articles/11524.windows-server-2012-hyper-v-network-virtualization-survival-guide.aspx). Хорошую сводку шагов для настройки виртуализации сети можно найти в блоге Microsoft TechNet «Step-by-Step: Hyper-V Network Virtualization» (http://blogs.technet.com/b/keithmayer/archive/2012/10/08/gettingstartedwithhypervnetworkvirtualization.aspx).
Расширяемый виртуальный коммутатор
В Hyper-V 3.0 появились важные изменения в архитектуре виртуального коммутатора (теперь именуемого расширяемым коммутатором). Этот виртуальный сетевой коммутатор уровня 2 может быть настроен на каждом узле Hyper-V и находится на перекрестке сетевого трафика между виртуальными машинами, между виртуальными машинами и узлом Hyper-V и трафиком с внешними компьютерами. Расширяемый коммутатор — компонент Hyper-V, который применяет политики виртуализации сети и располагает другими интересными функциями, относящимися к безопасности.
Партнеры Microsoft могут расширять возможности коммутаторов с использованием платформы Windows Filtering Platform (WFP) или фильтров network device interface specification (NDIS) для мониторинга и изменения сетевых пакетов, авторизации соединений или фильтрации трафика. Благодаря новой архитектуре расширяемый коммутатор поможет применить политики безопасности и изолирования при подключении виртуальных машин к сети. Виртуальный коммутатор — идеальное место для проверки данных, пересылаемых между виртуальными машинами, при поиске опасных программ. Классические средства противодействия вредоносному программному обеспечению и несанкционированному доступу обычно не проверяют этот трафик с его помощью и анализируют только трафик между физическими узлами. Некоторые партнеры Microsoft уже работают с расширяемыми коммутаторами: компания sFlow со своим расширением для мониторинга; 5nine, которая выпустила расширение виртуального брандмауэра; NEC, подготовившая расширение для мониторинга на основе OpenFlow. OpenFlow — важный открытый протокол для сетей SDN.
Новый расширяемый коммутатор также поддерживает определение PVLAN. Администраторы могут строить частные виртуальные локальные сети, назначая виртуальную машину основной виртуальной локальной сети, а затем одной или нескольким вторичным виртуальным локальным сетям. Используя эти частные виртуальные локальные сети, администраторы обеспечивают связь виртуальных машин только с виртуальными машинами с таким же идентификатором или идентификаторами VLAN, или с любой другой виртуальной машиной с таким же основным идентификатором VLAN, независимо от дополнительного идентификатора VLAN. Как отмечалось выше, использование частных виртуальных локальных сетей не позволяет уменьшить сложность управления VLAN с охватом виртуальных и физических сетевых устройств. Эти проблемы можно решить только с помощью виртуализации сети.
Еще одна мощная функция расширяемого коммутатора — политики изоляции на основе списков контроля доступа ACL, которые можно определить и применять на виртуальных портах расширяемого коммутатора. В сущности, в этих политиках перечислены правила разрешения и запрета, которые изолируют виртуальные машины и не позволяют им связываться с другими виртуальных машин в зависимости от IP- или MAC-адресов. Политики изоляции расширяемого коммутатора можно определить и из диспетчера VMM.
Наконец, в расширяемом коммутаторе реализованы такие новые функции безопасности, как DHCP Guard, разгрузка операций IPsec Task Offload, задачи IPsec и защита от подделки протокола разрешения адресов Address Resolution Protocol (ARP). С помощью DHCP Guard можно запретить виртуальным машинам работать в качестве сервера DHCP. DHCP Guard отвергает любые пакеты, отправляемые виртуальными машинами, которые указывали бы, что это сервер DHCP. DHCP Guard — свойство, которое можно настроить для любого сетевого адаптера виртуальной машины. Сделать это можно из диспетчера Hyper-V, в разделе дополнительных параметров сетевого адаптера в свойствах виртуальных машин, как показано на экране 2. Рекомендуется включить этот режим при создании «золотого» образа виртуальных машин.
|
|
| Экран 2. Включение DHCP Guard |
Разгрузка операций IPsec позволяет Hyper-V передать обработку, связанную с IPsec, в сетевой адаптер. Это возможно только в том случае, если сетевой адаптер поддерживает данную функцию. Разгрузка операций IPsec позволяет сократить рабочую нагрузку на процессор узла Hyper-V, связанную с использованием алгоритмов шифрования IPsec. Можно также включить этот режим из диспетчера Hyper-V: используйте раздел Hardware Acceleration в параметрах сетевого адаптера в свойствах виртуальных машин, как показано на экране 3.
|
|
| Экран 3. Включение разгрузки операций IPsec |
Расширяемый коммутатор обеспечивает защиту от подмены ARP, чтобы вредоносные виртуальные машины не могли предпринять атаку типа man-in-the-middle. В ходе такой атаки вредоносная машина использует ложные сообщения ARP, чтобы связать фальшивые MAC-адреса с не принадлежащими ей IP-адресами. В результате обманутые машины могут отправлять сообщения вредоносной машине. Чтобы включить защиту от подмены ARP, необходимо оставить флажок Enable MAC address spoofing (включить спуфинг MAC-адресов) в изначальном состоянии (сброшен).
Чтобы упростить настройку расширяемого коммутатора и его расширений, Microsoft предоставляет команды PowerShell. Вы можете использовать их для создания автоматизированных сценариев для настройки, мониторинга и диагностики расширяемого коммутатора.
Упрощенное делегирование и расширение BitLocker
В Hyper-V 3.0 упрощено административное делегирование благодаря появлению локальной группы безопасности Hyper-V Administrators. Члены новой группы имеют полный доступ ко всем функциям Hyper-V. Администраторам следует использовать эту группу для управления доступом к Hyper-V вместо того, чтобы добавлять пользователей к локальной группе Administrators. Кроме того, новая группа отчасти заменяет диспетчер Windows Authorization Manager (AzMan), который в прошлом был единственным доступным способом организации административного делегирования в Hyper-V. Администраторы могут по-прежнему использовать AzMan для делегирования, требующего большего уровня детализации и выходящего за рамки назначения полной роли администратора Hyper-V.
Наконец, нужно указать, что в Server 2012 можно воспользоваться новыми функциями шифрования BitLocker на уровне томов для защиты конфиденциальности и целостности образов виртуальных машин, хранящихся в местах с ненадежной физической защитой. В Server 2012 технология BitLocker расширена для шифрования томов операционной системы и данных на дисках в отказоустойчивых кластерах, в том числе общих томах кластеров. Дополнительные сведения можно найти в статье «BitLocker в Windows 8», опубликованной в Windows IT Pro/RE № 10 за 2012 год.
Важные отличия от средств безопасности vSphere
Новые функции безопасности — важное отличие Hyper-V от ближайшего конкурента, VMware vSphere. Хороший пример — расширяемый коммутатор Hyper-V. VMware также предоставляет виртуальный сетевой коммутатор, но он доступен только в редакции высокого уровня vSphere Enterprise Plus, цена которой, естественно, выше. Коммутатор vSphere не открытый, не расширяемый и не располагает передовыми функциями защиты (например, DHCP Guard и списки ACL виртуального порта) коммутатора Hyper-V. Чтобы дополнить vSphere такими функциями, необходимо приобрести дополнительные программы, например компонент App комплекса VMware vCloud Networking and Security (vCNS).
То же справедливо и для компонента Hyper-V Network Virtualization. Чтобы получить аналогичную функциональность в среде vSphere, потребителям необходимо обратиться к комплексу vCNS, в котором реализована технология VXLAN. Для VXLAN требуется коммутатор vSphere Distributed Switch (VDS), который есть только в редакции высокого уровня vSphere. Ожидается, что VMware скоро реализует централизованно программируемые сети SDN благодаря приобретению компании Nicira.
Отменная гибкость
Таким образом, Hyper-V 3.0 располагает мощными новыми функциями безопасности, которые позволят повысить гибкость и управляемость многоабонентских «облаков» на основе Hyper-V. Пришло время поближе познакомиться с новым продуктом Hyper-V. Кроме того, обязательно изучите новые возможности VVM SP1, незаменимый инструмент для управления развертыванием Hyper-V.
В данной инструкции мы рассмотрим варианты настройки сетей Hyper-V, расскажем для чего служат каждый тип виртуального коммутатора и базовую настройку каждого из них.
Используются 2 виртуальные машины на ОС Windows Server 2019. Для выполнения действий ниже необходимо иметь процессор с поддержкой аппаратной виртуализации, а также в настройках BIOS/UEFI включить виртуализацию. Также необходимо установить Hyper-V.
Для того, чтобы создать виртуальное сетевое устройство необходимо зайти в Диспетчер Hyper-V → Диспетчер виртуальных коммутаторов. На выбор Hyper-V предлагает 3 типа коммутаторов: внешний, внутренний и частный. Разберемся для чего нужен каждый из них.
Настройка внешней сети
Если вам необходимо, чтобы ваша виртуальная машина была доступна в вашей локальной сети и могла выходить в интернет, то выберите тип внешний.
Для этого в диспетчере виртуальных коммутаторов выберете внешний коммутатор, нажмите создать виртуальный коммутатор присвойте ему имя, а затем подключите его к вашей виртуальной машине.
Рисунок 1 — Диспетчер виртуальных коммутаторов
Для этого зайдите в параметры виртуальной машины, выберите слева пункт Установка оборудования, затем в списке справа сетевой адаптер → добавить.
Рисунок 2 — Параметры сетевого адаптера
Далее перейдите в пункт слева сетевой адаптер и в списке виртуальный коммутатор выберете ваш новый виртуальный коммутатор. Теперь он должен появиться внутри ВМ.
Принцип работы с ним практически не отличается от работы с сетевым адаптером на обычном компьютере. В настройках сети вам необходимо будет прописать IP вашего сетевого шлюза (роутера/свича) и назначить IP машины.
Для этого нужно открыть выполнить ввести и открыть ncpa.cpl на виртуальной машине, нажать ПКМ на сетевой адаптер vEthernet (в случае, если на вашей ВМ установлен только один виртуальный сетевой адаптер, то в оснастке он будет единственным), зайти в Свойства → IP версии 4 → Свойства и прописываем IP-адрес, маску подсети и адрес сетевого шлюза.
Далее на ВМ включите сетевое обнаружение. Зайдите в Панель управления → Центр управления сетями и общим доступом → Изменить дополнительные параметры общего доступа и в каждом профиле сети включите сетевое обнаружение.
Рисунок 3 — Настройка общего доступа
Затем попробуйте запустить ping до машины по этому внешнему адресу. Если ВМ пингуется, значит она доступна для других устройств в локальной сети.
Настройка внутренней сети
Если вы хотите настроить доступ с вашей хост-машины и между виртуальными машинами, то выбирайте тип внутренний.
В данном случае сетевой шлюз указывать не нужно; только прописать IP-адрес и маску подсети и включить сетевое обнаружение на ВМ.
Также после того, как вы создали внутренний коммутатор, на хост-машине зайдите в выполнить (Win+R) → введите ncpa.cpl → Enter. Там вы обнаружите Hyper-V Virtual Ethernet Adatpter, зайдите в свойства этого устройства и также пропишите IP-адрес и маску подсети в свойствах IPv4 в свойствах адаптера, чтобы хост-машина смогла взаимодействовать с ВМ по внутренней сети.
Обратите внимание! Для того, чтобы виртуальные машины и хост-машина смогли общаться между собой по внутреннему виртуальному коммутатору, необходимо, чтобы они были в одной подсети.
Например:
Вы назначили ВМ1 IP-адрес 187.255.1.1 и маску подсети 255.255.255.0
Значит, у ВМ2 и хост-машины должен быть IP-адрес в диапазоне 187.255.1.2-254 и такая же маска подсети.
Проверяем работу внутренней сети так же через PING.
Рисунок 4 — Скриншот с хост-машины
Настройка частной сети
Если вам нужна сетевая коммуникация только между ВМ, то выберите частную сеть.
Частная сеть практически ничем не отличается от внутренней; только тем, что хост-машина не может подключаться к виртуальным машинам.
Действия для настройки частной сети идентичны таковым при внутренней, с тем отличием, что виртуальный сетевой адаптер не появится на хост-машине, и вам нужно будет только прописать сетевые конфигурации ВМ в ncpa.cpl.
Что такое Default Switch?
Этот тип виртуального коммутатора создаётся гипервизором автоматически и использует технологию NAT для выхода в интернет.
Подходит только в тех случаях, когда на ВМ вам нужен только выход в интернет.
IP-адрес назначается автоматически и динамически, что значит, что он будет постоянно меняться, а hostname не успевать обновляться, поэтому не подходит для настройки сетевого взаимодействия между виртуальными машинами и устройствами в локальной сети.
Видеоинструкция
Продолжая цикл статей посвященный виртуализации, сегодня мы поговорим о настройке сети в Hyper-V. Основное внимание мы уделим теории, а именно разберем как устроены виртуальные сети и как они взаимодействуют с реальными. Потому что, как показывает практика, многие администраторы, в отсутствие простых и понятных материалов по данному вопросу, вынуждены осваивать настройку сети в Hyper-V методом «научного тыка».
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
С одной стороны, ничего сложного в настройке сетей для виртуальных машин нет, с другой многие начинают путаться во всех этих адаптерах, с трудом понимая, где реальный, где виртуальный, и чем они друг от друга отличаются. Постараемся внести ясность.
За настройку сетей в Hyper-V отвечает Диспетчер виртуальных коммутаторов, если мы откроем его, то увидим следующую картину:
Как видим, нам доступно создание трех типов сетей: внешней, внутренней и частной. Разберемся подробнее, для чего нужны эти сети и в чем разница между ними.
Внешняя сеть
Самый распространенный тип сети, который позволяет виртуальным машинам взаимодействовать с внешними сетями и хостом. При ее создании необходимо выбрать один из физических сетевых адаптеров, через который данная виртуальная сеть будет соединяться с внешними сетями.
Как мы уже писали, основу виртуальной сети составляет виртуальный коммутатор. При создании внешней сети, Hyper-V создает виртуальный коммутатор, к которому через виртуальные сетевые адаптеры (vNIC) подключаются как виртуальные машины, так и хост. Физический адаптер отключается от хоста и по сути становится физическим портом виртуального коммутатора, через который он подключается к внешней сети.
В этом нетрудно убедиться, после создания внешней сети на хосте появляется Адаптер Ethernet для виртуальной сети Hyper-V, на который переносятся все настройки с физического адаптера.
А в свойствах физического адаптера остался только Расширяемый виртуальный сетевой коммутатор в Hyper-V.
В случае с внешней сетью следует четко понимать, что хост, точно также как и виртуальные машины, подключается к виртуальному коммутатору через виртуальный сетевой адаптер. Физический сетевой адаптер, после создания внешней сети становится портом виртуального коммутатора, через который он подключается к внешней сети. Поэтому все сетевые настройки хоста следует производить только на виртуальном сетевом адаптере.
Также имеется возможность создания внешних сетей, изолированных от хоста, в этом случае виртуальный сетевой адаптер не создается, а физический интерфейс отключается от хоста, обслуживая только виртуальный коммутатор. Для этого при создании внешней сети необходимо снять галочку Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру.
Данная конфигурация позволяет успешно виртуализировать пограничные сетевые устройства, надежно отвязав их от внутренней сети и хоста. Например, мы можем создать две внешних сети, одна из которых будет подключена к локальной сети, вторая к интернет и осуществлять выход во внешнюю сеть через роутер на виртуальной машине, при этом и хост, и локальная сеть будут надежно изолированы от интернет, несмотря на то, что кабель внешней сети физически будет подключен к сетевому адаптеру хоста.
Внутренняя сеть
Как следует из ее названия, внутренняя сеть предназначена для подключения виртуальных машин и хоста и не предусматривает соединения с внешними сетями. При ее создании также создается виртуальный сетевой адаптер для хоста, который оказывается подключен к виртуальному коммутатору внутренней сети и должен быть сконфигурирован в соответствии с настройками виртуальной сети.
К внешней сети хост остается подключен через физический адаптер, настройки которого не затрагиваются. Данная конфигурация чаще всего используется для учебных и исследовательских целей, позволяя создавать и моделировать различной сложности сетевые конфигурации не затрагивая рабочие сети предприятия.
Внутренняя сеть c NAT
Данная возможность появилась начиная с Windows Server 2016, Hyper-V Server 2016 и Windows 10. Подробнее читайте в нашей статье: Настраиваем сеть NAT в Hyper-V
Частная сеть
Частная сеть отличается от внутренней тем, что виртуальный коммутатор может быть подключен только к виртуальным машинам и изолирован от хоста.
Данный вид сетей может быть использован также в учебных и исследовательских целей, а также для создания изолированных участков сети, например DMZ.
В этом случае связь между внешней и частной сетью будет осуществляться через одну из виртуальных машин, которая должна быть подключена к обеим сетям.
Как видим, Hyper-V дает в руки администратора весьма гибкий и мощный инструмент, позволяющий создавать весьма сложные сетевые конфигурации и управлять ими.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Процесс перехода от традиционной инфраструктуры к виртуальной может оказаться физически (да и психологически) сложной задачей для администратора, поскольку терминология и возможности систем виртуализации иногда отличаются от изученного ранее. Для тех из вас, кто изучает различные аспекты виртуализации и системы Hyper-V, мы продолжим публиковать полезные статьи, подробно рассматривающие многочисленные возможности системы Hyper-V.
Сегодня я хочу рассказать о виртуальном коммутаторе Hyper-V (vSwitch) в Windows Server 2012 R2. Но сперва уделите немного времени чтению следующих вопросов:
- Что такое виртуальный коммутатор Hyper-V vSwitch?
- Какие типы коммутаторов vSwitch существуют в системе Hyper-V и в чем их различия?
- Что представляет собой команда PowerShell для удаленной настройки vSwitch?
- Как я могу настроить ВМ (виртуальную машину) на обнаружение только внутренней сети, но не интернета?
Какой-нибудь из этих вопросов кажется вам знакомым? Если да, прочитайте эту статью до конца. У меня есть ответы!
Hyper-V vSwitch — это программно-определяемый коммутатор трафика сети Ethernet, работающий на канальном уровне (layer-2). С его помощью сетевые администраторы могут подключать ВМ как к физическим, так и к виртуальным сетям. Он доступен по умолчанию при установке Hyper-V Manager и содержит улучшенные средства обеспечения безопасности и отслеживания системных ресурсов. Как и в случае других возможностей среды Hyper-V, в состав каждой новой версии Hyper-V входит улучшенная версия vSwitch. В настоящее время коммутатор vSwitch считается очень надежным, но в него продолжают вносить улучшения. Например, в среде Hyper-V 4.0 (той, что в Windows 2012 R2) предусмотрено множество возможностей для внутреннего изолирования и защиты сети от вредоносных ВМ.
Поскольку я не вижу смысла в теории без практики, хотелось бы перейти в Hyper-V Manager и позволить вам самим увидеть и оценить все возможности.
Установка Hyper-V vSwitch
В ходе установки среды Hyper-V предварительная настройка V vSwitch не выполняется. Если вы попытаетесь создать ВМ сразу после процесса установки, подключиться к сети вам не удастся. Чтобы настроить сетевую среду, выберите Virtual Switch Manager (Менеджер виртуального коммутатора) на правой панели приложения Hyper-V Manager.
Рис. 1. Hyper-V Manager
Virtual Switch Manager упрощает настройку параметров коммутатора vSwitch и глобальной сети, что дает возможность изменять пространство стандартных MAC-адресов (примечание: изменение пространства MAC не будет влиять на существующий виртуальный коммутатор).
Создание виртуального коммутатора простая процедура. Для создания доступно три типа коммутаторов vSwitch:
- Внешний vSwitchсоединит физический сетевой адаптер хоста Hyper-V с виртуальным и затем предоставит вашим ВМ доступ за пределы хоста — в вашу физическую сеть и интернет (если физическая сеть подключена к интернету).
- Внутренний vSwitchследует использовать для построения независимой виртуальной сети, в которой подключенные ВМ будут «видеть» друг друга, а также хост гипервизора.
- Частный vSwitchсоздаст виртуальную сеть, в которой все входящие в соединение ВМ будут «видеть» друг друга, но не хост Hyper-V. В этой тестовой среде ВМ будут полностью изолированы.
Рис.2 vSwitch Manager
Создание внешнего коммутатора vSwitch
Мастер создания предлагает вам выбор нескольких настроек при создании внешнего vSwitch.
- Можно выбрать нужный физический сетевой адаптер, если подходящих vSwitch у вас несколько.
- Опция Allow management OS to share this network adapter(Разрешить управляющей операционной системе создавать общий доступ к этому сетевому адаптеру) по умолчанию включена. Отключение этой опции лишит ОС гипервизора возможности сетевого подключения. Будьте осторожнее при создании vSwitch удаленно. Это может полностью разорвать соединение с удаленным хостом.
- SR-IOV(Single Root I/O Virtualization) (Виртуализация ввода-вывода с единым корнем) позволяет подготовить такую конфигурацию, которая может увеличить пропускную способность сети путем перенаправления трафика напрямую в ВМ в обход коммутатора vSwitch. Информация о включении опции SR-IOV доступна здесь. Необходимо учесть несколько аппаратных и системных требований: совместимость BIOS, поддержка SLAT процессором и сетевой картой SR-IOV PCIe в вашей системе. Убедитесь заранее, что вы знаете, что делаете.
ПРИМЕЧАНИЕ: Вы не сможете включить опцию SR-IOV для существующего коммутатора vSwitch. - VLAN ID: Эта настройка разрешает создание виртуальной локальной сети (VLAN) в управляющей ОС. Верно это и для физической среды, настройка позволяет выделить трафик гипервизора путем предоставления отдельных широковещательных доменов внутри единой сети.
Рис. 3. Создание внешнего коммутатора vSwitch
Нажав кнопку Apply (Применить), будьте готовы потерять возможность физического сетевого подключения на время, пока среда Hyper-V выключит физический сетевой адаптер, настроит коммутатор vSwitch и заново их включит:
Рис. 4. Предупреждение при создании внешнего vSwitch
Процедура создания внутреннего и частного коммутатора vSwitch аналогична, хотя некоторые настройки, такие как общий доступ к сети и SR-IOV будут недоступны и выделены серым цветом, что связано с самим характером этих коммутаторов.
Рис. 5. Создание внутреннего коммутатора vSwitch
ПРИМЕЧАНИЕ: Возможна автоматизация процедуры с помощью скрипта PowerShell, как и в случае других административных операций Windows 2012 R2. Полный синтаксис скрипта нуждается в проверке на сайте TechNet, но несколько примеров скриптов PS приведено ниже.
ПОДСКАЗКА: Не забудьте запустить консоль PowerShell с повышенными правами.
Следующая команда создает внешний коммутатор vSwitch для сетевого адаптера “Ethernet”:
New-VMSwitch -Name "External vSwitch" -NetAdapterName "Ethernet" -AllowManagementOS 1 -Notes "PowerShell example of External vSwitch creation"
Следующая команда создает внутренний коммутатор vSwitch:
New-VMSwitch -Name "Internal vSwitch" -SwitchType "Internal" -Notes "PowerShell example of Internal vSwitch creation"
Тип коммутатора vSwitch определяется параметром “-SwitchType «Internal/Private» или в случае внешнего vSwitch одним из следующих параметров: “-NetAdapterName «имя физического сетевого адаптера» / -NetAdapterInterfaceDescription «описание физического сетевого адаптера»”.
Создав коммутаторы vSwitch, вы можете их использовать в настройках сетевого подключения ваших ВМ.
Рис. 6. Мастер создания новой ВМ
ПОДСКАЗКА: Проверьте, к какому из всех vSwitch подключены ваши ВМ, с помощью команды:
Get-VMNetworkAdapter -VMName *
Подключение к сети ВМ
Имейте в виду, что подключенные к внутреннему или к частному коммутатору vSwitch виртуальные машины получат IP-адрес автоматически только в случае, если в той же виртуальной сети присутствует DHCP-сервер. Если DHCP-сервер отсутствует, выполните небольшую пост-конфигурацию ВМ, подключенных к частному vSwitch:
1. Перейдите в панель управления Network Connections (Сетевые подключения) ОС гипервизора и найдите подключение, относящееся к внутреннему vSwitch. Настройте статический IP-адрес и маску подсети вручную:
Рис. 7. Пост-конфигурация внутреннего коммутатора
2. Включите ВМ и задайте сетевому адаптеру ВМ нужный статический IP-адрес той же подсети, чтобы установить сетевое подключение. Задав правильные настройки, вы сможете проверить с помощью ping-запроса гипервизору, все ли настроено верно.
Рис. 8. Проверка возможности сетевого подключения внутреннего коммутатора
Для настройки частного коммутатора vSwitch используйте статические IP-адреса для всех ВМ и разместите их в одной подсети.
Вот и все! Позже я опубликую еще несколько полезных материалов о среде Hyper-V. А пока поделитесь со мной своим опытом виртуальной сетевой коммутации в среде Hyper-V. Какие-либо сложности, подсказки или комментарии? Все то, чем вы хотели бы поделиться.
Содержание
- Установка Hyper-V в Windows 10
- Проверьте следующие требования
- Включение Hyper-V с помощью PowerShell
- Включение Hyper-V с помощью CMD и DISM
- Включение роли Hyper-V через раздел «Параметры»
- Ошибка Hyper-V «Не удаётся запустить виртуальную машину, поскольку не выполняется низкоуровневая оболочка»
- Системные требования
- Хранилище BCD
- AMD Bulldozer
- Технологии виртуализации
- Как включить виртуализацию Hyper-V Windows 10
- Системные требования Hyper-V
- Как включить Hyper-V в Windows 10
- Панель управления
- Windows PowerShell
- Установка и настройка Hyper-V
- 🐹 Microsoft Hyper-V: Установка и настройка на Windows 10.
- Содержание:
- 1. Описание программы.
- 2. Установка гипервизора.
- 3. Как запустить гипервизор.
- 4. Как создать виртуальный коммутатор.
- 5. Как создать виртуальную машину.
- 6. Подключение и запуск виртуальной машины.
- 7. Как удалить виртуальную машину.
- 8. Работа с контрольными точками.
Включение Hyper-V для создания виртуальных машин в Windows 10.
Hyper-V можно включить разными способами, в том числе используя панель управления Windows 10, PowerShell или с помощью средства обслуживания образов развертывания и управления ими (DISM). В этом документе последовательно описан каждый из указанных способов.
Примечание. Механизм Hyper-V встроен в Windows в качестве дополнительной функции. Скачать Hyper-V нельзя.
Проверьте следующие требования
Роль Hyper-V невозможно установить в Windows 10 Домашняя.
Выполните обновление с выпуска Windows 10 Домашняя до выпуска Windows 10 Pro, открыв раздел Параметры > Обновление и безопасность > Активация.
Дополнительные сведения и советы по устранению неполадок см. в статье Требования к системе для Hyper-V в Windows 10.
Включение Hyper-V с помощью PowerShell
Откройте консоль PowerShell от имени администратора.
Выполните следующую команду:
Если не удается найти команду, убедитесь, что вы используете PowerShell от имени администратора.
После завершения установки выполните перезагрузку.
Включение Hyper-V с помощью CMD и DISM
Система обслуживания образов развертывания и управления ими (DISM) позволяет настраивать ОС Windows и образы Windows. Помимо всего прочего? средство DISM может включать функции Windows во время выполнения операционной системы.
Чтобы включить роль Hyper-V с помощью DISM, выполните указанные ниже действия.
Запустите PowerShell или сеанс CMD от имени администратора.
Введите следующую команду:
Дополнительные сведения о DISM см. в разделе Техническое руководство по DISM.
Включение роли Hyper-V через раздел «Параметры»
Щелкните правой кнопкой мыши кнопку Windows и выберите пункт «Приложения и компоненты».
Выберите Программы и компоненты справа в разделе связанные параметры.
Выберите пункт Включение или отключение компонентов Windows.
Выберите Hyper-V и нажмите кнопку ОК.
После завершения установки вам будет предложено перезапустить компьютер.
Источник
Ошибка Hyper-V «Не удаётся запустить виртуальную машину, поскольку не выполняется низкоуровневая оболочка»
Что это за ошибка, и как её исправить.
Окно с такой ошибкой является универсальной трактовкой, причина может крыться в нескольких вещах.
Системные требования
Если сама Windows не соответствует требованиям для работы с Hyper-V, а десктопные выпуски не все позволяют работать с этим компонентом, он попросту не активируется в системе. Но есть ещё аппаратные требования. Их несоответствие может не влиять на активацию гипервизора, но в дальнейшем стать причиной появления такой ошибки.
Для работы Hyper-V необходимо:
• Не менее 4 Гб RAM;
• 64-битный процессор с поддержкой SLAT и технологии виртуализации.
Хранилище BCD
bcdedit /set hypervisorlaunchtype auto
После этого осуществляем перезагрузку.
AMD Bulldozer
Hyper-V не работает с процессорами компании AMD с архитектурой Bulldozer.
Технологии виртуализации
Ещё один важный нюанс: для процессоров Intel в BIOS должны быть отключены специфические технологии Intel VT-d и Trusted Execution. С ними встроенный в Windows гипервизор не дружит. Вот примерно так должны выглядеть настройки BIOS для работы с Hyper-V: технология виртуализации включена, а специфические технологии – выключены.
Источник
Как включить виртуализацию Hyper-V Windows 10
Сервер виртуализации — это физический компьютер, располагающий необходимыми ресурсами для работы виртуальных машин. С помощью диспетчера Hyper-V можно создавать, настраивать и осуществлять управление виртуальными машинами на сервере виртуализации.
С помощью виртуальных машин можно выполнять различные задач. Каждая виртуальная машина запускается в изолированной среде выполнения, что позволяет использовать на компьютере различные операционные системы и приложения.
Данная статья расскажет как включить виртуализацию Hyper-V Windows 10. Первым делом рассмотрим как проверить системные требования Hyper-V, а уже потом включению Hyper-V и настройке виртуальной машины.
Системные требования Hyper-V
Итак если говорить о системных требованиях к операционной системе, на которой будет разворачиваться гипервизор под названием Hyper-V, то подойдут редакции Windows 10 Enterprise, Professional и Education. Обязательно должна быть 64 — битная версия операционной системы Windows 10, поскольку 32 — версии не имеют возможности использовать Hyper-V.
Помимо этого Вам потребуется 64 — битный процессор, который поддерживает технологии виртуализации, такие, как VM Monitor Mode Extension и поддержка Second Level Address Translation. Рекомендуется использовать минимум 4 ГБ оперативной памяти, если же запускать на меньшем объеме, тогда виртуальной машине ничего не достанется.
А также необходимо будет включить эти самые технологии виртуализации, а также включить Hardware Enforced Data Execution Prevention (DEP). Без этой технологии у Вас не будут запускаться виртуальные машины. Есть ряд особенностей связанных с конкретной моделью BIOS или UEFI. Некоторые технологии могут конкурировать с виртуализацией и соответственно не позволять запускать виртуальные машины.
Операционная система Windows 10 имеет инструмент проверки совместимости оборудования с установкой Hyper-V, который пригодиться новичкам. С помощью утилиты systeminfo.exe мы увидим параметры по требованиях к Hyper-V.
Внизу окна находим пункт требований Hyper-V и проверяем поддерживается ли установка виртуальной машины на Вашем компьютере. Если же Вы найдете следующие параметры значений, тогда проблем с установкой Hyper-V на эту машину у Вас не возникнет:
Как включить Hyper-V в Windows 10
Панель управления
Установка компонентов пройдёт достаточно быстро и система запросит перезагрузку системы. В процессе перезагрузки пользователь также увидит работу с обновлениями.
Windows PowerShell
Вместо Windows PowerShell можно использовать обычную командную строку. См. также как запустить командную строку в Windows 10.
Установка и настройка Hyper-V
Мастер поможет Вам создать виртуальную машину. Виртуальные машины могут использоваться вместо физических компьютеров в разных целях. Вы можете выполнить настройку виртуальной машины с помощью мастера или с помощью диспетчера Hyper-V.
Перед созданием виртуальной машины в Hyper-V необходимо скачать образ операционной системы. Можно легко скачать образ Windows 10 с официального сайта Microsoft.
После подключения к новой виртуальной машине откроется новое окно с образом, который выбирался ранее. Дальше достаточно управлять и следовать шагам установке операционной системы.
Включить виртуализацию Hyper-V на Windows 10 можно используя мастер создания виртуальной машины в диспетчере Hyper-V. Но перед включением убедитесь что Ваш компьютер отвечает системным требованиям Hyper-V. Только потом рекомендуется включать, устанавливать и настраивать виртуальную машину в Hyper-V.
Источник
🐹 Microsoft Hyper-V: Установка и настройка на Windows 10.
Опубликовано 2020-08-14 · Обновлено 2022-02-07
Содержание:
1. Описание программы.
Технология виртуализации Microsoft Hyper-V — это система встроенной аппаратной виртуализации предоставляющая гостевым системам прямой доступ без участия промежуточных виртуальных драйверов, замедляющих работу, к устройствам компьютера: диск, память, процессор и так далее.
Технология виртуализации Hyper-V включена во многие версии Windows 10. Hyper-V позволяет запускать виртуализированные компьютерные системы поверх физического узла. Эти виртуализированные системы можно использовать и контролировать как физические компьютерные системы, но они находятся в виртуализированной и изолированной среде. Специальное программное обеспечение, называемое низкоуровневой оболочкой, управляет доступом между виртуальными системами и физическими аппаратными ресурсами. Виртуализация обеспечивает быстрое развертывание компьютерных систем, быстрое восстановление системы до предыдущего рабочего состояния и возможность миграции систем между физическими узлами.
В частности, Hyper-V предоставляет возможность выполнять виртуализацию оборудования. Это означает, что каждая виртуальная машина работает на виртуальном оборудовании. Hyper-V позволяет создавать виртуальные жесткие диски, виртуальные коммутаторы и ряд других виртуальных устройств, каждое из которых можно добавить в виртуальную машину.
Механизм Hyper-V встроен в Windows 10 в качестве дополнительной функции. Скачать Hyper-V нельзя.
Виртуализация позволяет выполнять следующие операции:
Microsoft Azure – облачная платформа компании Microsoft. Предоставляет возможность разработки, выполнения приложений и хранения данных на серверах, расположенных в распределённых дата-центрах.
Системные требования:
Hyper-V доступен в 64-разрядных версиях Windows 10: профессиональная, корпоративная и для образовательных учреждений. Он недоступен в версии Windows 10: домашняя.
Большинство компьютеров работают под управлением Hyper-V, однако каждая виртуальная машина работает под управлением полностью отдельной операционной системы. Как правило, на компьютере с 4 ГБ ОЗУ можно запустить одну или несколько виртуальных машин, однако для запуска дополнительных виртуальных машин либо установки и запуска ресурсоемкого программного обеспечения, такого как: игры, видеоредакторы или программы для технического проектирования, потребуются дополнительные ресурсы.
Преимущества:
Недостатки:
Основные возможности:
Ограничения:
Программы, которые зависят от наличия определенного оборудования, не будут нормально работать на виртуальной машине. Например, это игры или приложения, которым нужны графические процессоры. С приложениями, использующими таймеры длительностью менее 10 мс, например приложениями для микширования музыки в режиме реального времени или приложениями, чувствительными к задержкам, также возможны проблемы.
Кроме того, если включен Hyper-V, проблемы могут возникать и с чувствительными к задержкам высокоточными приложениями, работающими в операционной системе сервера виртуальных машин.
Это связано с тем, что при включенной виртуализации операционная система сервера виртуальных машин тоже работает поверх уровня виртуализации Hyper-V, как и гостевые операционные системы. Однако отличие операционной системы сервера виртуальных машин от гостевых операционных систем заключается в том, что она имеет прямой доступ к оборудованию, что обеспечивает правильную работу приложений с особыми требованиями к оборудованию.
Где взять:
Данный гипервизор невозможно просто скачать и установить на свой рабочий компьютер, потому что он уже интегрирован в современные операционные системы Windows, кроме версии Windows Home (Домашняя).
Так же может идти в виде отдельного гипервизора Windows Hyper-V Server для сервера.
Поддерживаемые операционные системы на виртуальной машине:
2. Установка гипервизора.
По умолчанию гипервизор в Windows деактивирован. Для его активации требуется выполнить некоторые действия, добавить его в компонентах Windows и установить. Для всех операционных систем семейства Windows установка будет примерно одинаковая. Разница будет заключаться только в графическом оформлении установки, которая зависит от версии операционной системы Windows в вашем распоряжении.
Если в вашем распоряжении версия Windows Home, то смело можете пропускать данный раздел курсов и переходить к описанию Oracle VM VirtualBox, так как в версию Windows Home гипервизор не интегрирован и его нужно будет устанавливать с помощью специального установщика с сайта Microsoft. Рассматривать как это сделать, в рамках программы этих курсов, мы не будем.
Убедитесь, что в настройках BIOS включена поддержка аппаратной виртуализации, как показано ниже.
Давайте посмотрим, как установить роль Hyper-V в Windows, выполнив следующие шаги:
1. Откройте стандартный Проводник Windows и перейдите в Панель управления.
2. В Панели управления переходим во вкладку Удаление программ.
3. В Удалении программ переходим во вкладку включение или отключение компонентов Windows.
4. Откроется окно с компонентами. Выбираем компонент Hyper-V и ставим галочки на оба пункта, которые содержатся в нём: Платформа Hyper-V и Средства управления Hyper-V. После выбора компонентов нажимаем клавишу ОК.
5. Начнется установка Hyper-V. Это займёт некоторое время.
6. В итоге установка завершится приглашением перезагрузить компьютер, чтобы компоненты вашей системы вступили в силу. Принимаем приглашение и перезагружаем Windows.
После перезагрузки компьютера в системе Windows появится Диспетчер Hyper-V. Любым удобным способом ищем и запускаем данную программу.
3. Как запустить гипервизор.
1. Нажмите сочетание клавиш Клавиша Windows + R, в открывшемся окне Выполнить введите (скопируйте и вставьте) virtmgmt.msc и нажмите клавишу Enter.
В результатах поисковой выдачи выберите Диспетчер Hyper-V или нажмите правой кнопкой мыши и в контекстном меню выберите пункт На начальный экран или Закрепить на панели задач (если вы часто будете использовать Диспетчер Hyper-V).
3. Также запустить Диспетчер Hyper-V, вы можете из списка программ меню Пуск в папке Средства администрирования.
4. Также вы можете создать ярлык для запуска Диспетчера Hyper-V, для этого нажмите правой кнопкой мыши на рабочем столе и в появившемся контекстном меню выберите Создать —> Ярлык, затем в окне Создать ярлык в поле Укажите расположение объекта: введите virtmgmt.msc и нажмите кнопку Далее.
В следующем окне, в поле Введите имя ярлыка введите например Диспетчер Hyper-V и нажмите кнопку Готово, в результате чего будет создан ярлык на рабочем столе с помощью которого вы сможете запустить Диспетчер Hyper-V.
При запуске Hyper-V любым удобным способом, вас поприветствует открывшийся интерфейс программы.
В нём потребуется нажать кнопку Подключиться к серверу:
Так как у вас гипервизор установлен локально, то и подключаться мы будем к Локальному компьютеру:
Далее гипервизор раскроет вам весь свой потенциал:
4. Как создать виртуальный коммутатор.
Настройка доступа к сети в Диспетчере Hyper-V настраивается отдельно. Для этого в Диспетчере Hyper-V слева в списке выберите пункт с именем вашего компьютера, и в правой части окна выберите Диспетчер виртуальных коммутаторов.
Диспетчер виртуальных коммутаторов помогает настроить vSwitch и глобальные сетевые параметры, которые просто позволяют вам изменить диапазон MAC-адресов по умолчанию, если вы видите какую-либо причину для этого.
Создать виртуальный коммутатор легко и доступно три типа vSwitch, которые описаны ниже:
В данном случае доступ виртуальной машины к интернету необходим, поэтому выбираем первый тип — внешнюю сеть и нажимаем Создать виртуальный коммутатор.
В окне свойств виртуального коммутатора задаем ему имя, это может быть какое угодно имя, в данном примере Virtual Network. Если на вашем компьютере есть и Wi-Fi адаптер и сетевая карта, выберите в пункте Внешняя сеть тот из сетевых адаптеров, который используется для доступа в Интернет. В данном случае используется Wi-Fi адаптер.
Будет открыта таблица с настройкой vSwitch, где мы будем заполнять поля, как показано ниже
После проделанных настроек нажмите кнопку OK.
Далее вам будет выдано предупреждение о том, что ожидающие изменения могут нарушить сетевое подключение, нажмите кнопку Да.
Виртуальный сетевой адаптер создан. Результат добавления виртуального коммутатора в Hyper-V на физической машине вы можете увидеть в окне Сетевые подключения, в результате был создан сетевой мост и виртуальный адаптер.
5. Как создать виртуальную машину.
Для создания виртуальной машины в диспетчере Hyper-V нажмите правой кнопкой мыши на имени компьютера и в появившемся контекстном меню выберите Создать —> Виртуальная машина.
В первом окне мастера создания виртуальной машины нажимаем кнопку Далее >.
В следующем окне задаем виртуальной машине имя, также можно сменить ее месторасположение (стандартное расположение для виртуальных машин – папка C:ProgramDataMicrosoftWindowsHyper-V ) на диске физического компьютера, указав нужный раздел диска и нужную папку с помощью кнопки Обзор, нажимаем кнопку Далее >.
Следующий шаг — это выбор поколения виртуальной машины. Выберите необходимое Поколение виртуальной машины (в данном случае выбрано Поколение 2) и нажмите кнопку Далее >.
Далее в окне выделения памяти оставляем предустановленные параметры, если физический компьютер имеет не более 4 Гб оперативной памяти. Если оперативной памяти больше 4 Гб, можно увеличить показатель, выделяемый при запуске виртуальной машины. Выберите нужный объем памяти и нажмите кнопку Далее >.
В окне Настройка сети в выпадающем списке Подключение: выберите ранее созданный виртуальный коммутатор и нажмите кнопку Далее >.
В окне Подключить виртуальный жесткий диск укажите желаемое место его расположения на диске, имя файла виртуального жесткого диска, а также задайте размер, которого будет достаточно для ваших целей и нажмите кнопку Далее >.
В данном случае оставлены параметры по умолчанию.
Следующим шагом будет указание пути к дистрибутиву Windows. Виртуальные машины второго поколения не предусматривают загрузку с физического CD/DVD-привода. Источниками загрузки дистрибутива гостевой операционной системы могут быть только сеть и ISO-образ. В данном случае это ISO-образ. Нажмите кнопку Далее >.
Затем в окне Завершение работы мастера создания виртуальной машины нажмите кнопку Готово.
6. Подключение и запуск виртуальной машины.
Перед запуском виртуальной машины требуется разрешить начало исполнения программного обеспечения с образа диска ISO. Для этого в Параметрах виртуальной машины в разделе Безопасность требуется Отключить безопасную загрузку.
Теперь виртуальную машину нужно подключить. Для этого нажмите правой кнопкой мыши на виртуальной машине и в контекстном меню выберите пункт Подключить. Команда Подключить присутствует и в правой части окна Диспетчера Hyper-V. Для подключения также можно сделать двойной клик левой кнопкой мыши на окне-превью выбранной виртуальной машины.
В открывшемся окне подключения нажмите зеленую кнопку Пуск.
Далее нажимаем любую кнопку, чтобы виртуальная машина загрузилась с ISO-образа.
Затем начнется обычный процесс установки Windows 10, как это происходило бы на физическом компьютере.
Как только начнется копирование файлов установки, можно закрыть окно подключения к виртуальной машине.
Закрытие окна подключения высвободит некоторые ресурсы физического компьютера для выполнения других задач, при этом виртуальная машина продолжит свою работу в фоновом режиме. Ее рабочие показатели будут отображаться в Диспетчере Нурег-V. Подключаться к виртуальной машине можно по мере необходимости выполнения в ней действий.
Выключить, завершить работу, сохранить, приостановить виртуальную машину или сбросить ее состояние, а также создать контрольную точку можно командами в диспетчере Нурег-V или кнопками в верхней панели окна подключения.
7. Как удалить виртуальную машину.
При необходимости вы можете удалить виртуальную машину Hyper-V, при этом виртуальная машина удаляется только из диспетчера Hyper-V.
При удалении виртуальной машины Hyper-V удаляется файл конфигурации виртуальной машины, но не удаляются виртуальные жесткие диски (*.VHDX-файлы).
Если виртуальная машина имеет какие-либо контрольные точки (snapshots), они удаляются и объединяются в файлы виртуального жесткого диска после удаления виртуальной машины.
Чтобы удалить виртуальную машину, откройте Диспетчер Hyper-V ( virtmgmt.msc ).
В списке установленных виртуальных машин выберите виртуальную машину Hyper-V, которую вы хотите удалить и выполните одно из следующих действий:
При появлении запроса на удаление виртуальной машины, нажмите кнопку Удалить.
8. Работа с контрольными точками.
Одно из главных преимуществ виртуализации — это возможность сохранять состояние виртуальной машины. В Hyper-V для этого используются контрольные точки виртуальной машины. Контрольную точку виртуальной машины можно создать перед изменением конфигурации программного обеспечения, применением обновления или установкой нового программного обеспечения. Если после изменения системы возникла проблема, виртуальную машину можно вернуть в состояние на момент создания контрольной точки.
8.1. Типы контрольных точек.
Hyper-V в Windows 10 включает два типа контрольных точек:
По умолчанию используются рабочие контрольные точки, но с помощью Диспетчера Hyper-V это можно изменить.
Как настроить тип контрольной точки:
8.2. Создание контрольных точек.
Создает контрольную точку того типа, который настроен для данной виртуальной машины. Сведения о том, как изменить тип контрольной точки, смотрите выше в этом же документе.
Чтобы создать контрольную точку, выполните указанные ниже действия:
8.3. Применение контрольных точек.
Если вы хотите вернуть виртуальную машину в состояние на определенный момент времени, примените существующую контрольную точку.
Как применить контрольную точку:
Выберите один из вариантов применения для создания и применения контрольной точки.
8.4. Переименование контрольных точек.
В определенной точке могут быть созданы много контрольных точек. Предоставление им понятного имени упрощает запоминание подробностей о состоянии системы при создании контрольной точки.
По умолчанию имя контрольной точки — имя виртуальной машины в сочетании с указанием даты и времени создания контрольной точки.
Имя должно содержать не более 100 знаков и не может быть пустым.
Как переименовать контрольную точку:
8.5. Удаление контрольных точек.
Удаление контрольных точек помогает освободить пространство на узле Hyper-V.
Контрольные точки хранятся в виде AVHDX-файлов в том же расположении, что и VHDX-файлы для виртуальной машины. При удалении контрольной точки Hyper-V для удобства объединяет AVHDX- и VHDX-файлы. После завершения AVHDX-файл данной контрольной точки будет удален из файловой системы.
Не следует удалять непосредственно AVHDX-файлы.
Чтобы полностью удалить контрольную точку:
8.6. Экспорт контрольных точек.
Экспорт объединяет контрольные точки в пакет как виртуальную машину, так что контрольную точку можно переместить в новое место. После выполнения импорта контрольная точка восстанавливается как виртуальная машина. Экспортированные контрольные точки можно использовать для резервного копирования.
8.7. Включение и отключение контрольных точек.
8.8. Настройка расположения контрольной точки.
Если у виртуальной машины нет контрольных точек, можно изменить место, в котором хранятся файлы конфигурации контрольных точек и файлы состояний сохранения.
По умолчанию для хранения файлов конфигурации контрольных точек используется расположение:
8.9. Демонстрация контрольной точки.
Создадим и применим стандартную и рабочую контрольные точки.
В этом примере вы внесете простое изменение в виртуальную машину и увидите изменение ее поведения.
8.9.1. Стандартная контрольная точка.
Теперь, когда контрольная точка создана, внесите изменения в виртуальную машину, а затем примените контрольную точку, чтобы вернуть виртуальную машину в сохраненное состояние.
Обратите внимание, что после применения контрольной точки восстановлен не только текстовый файл, но и состояние системы на момент создания контрольной точки. В этом случае Блокнот будет открыт с загруженным текстовым файлом.
8.9.2. Рабочая контрольная точка.
Теперь рассмотрим рабочие контрольные точки. Эта процедура почти идентична работе со стандартными контрольными точками, но имеет немного другие результаты. Перед началом работы убедитесь, что у вас есть виртуальная машина и выбран рабочий тип контрольной точки.
Изменение виртуальной машины и создание рабочей контрольной точки:
Теперь, когда контрольная точка создана, внесите изменения в систему, а затем примените контрольную точку, чтобы возвратить виртуальную машину в сохраненное состояние.
Обратите внимание, что после применения рабочей контрольной точки виртуальная машина отключается.
Источник
Search code, repositories, users, issues, pull requests…
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
Вы тут: Главная → Windows → Нюансы виртуальных коммутаторов Hyper-V и приоритета сетевых интерфейсов
Однажды я заметил, что с ноутбука очень долго загружались фотографии в Google Photos. Я посмотрел торренты, и они тоже раздавались со скоростью значительно ниже ожидаемой. Зайдя в SpeedTest, я увидел такую картину:
Я начал разбираться…
[+] Сегодня в программе
Первый этап диагностики
Мой ноутбук был подключен по Wi-Fi к двухдиапазонному маршрутизатору ASUS RT-N66U. Низкая скорость наблюдалась на обеих частотах, однако в других ПК и телефоне все было нормально. С подключением к проводной сети при отключенном Wi-Fi все тоже было в порядке.
Все пути вели к беспроводному адаптеру Intel Centrino Advanced-N 6205 в ноутбуке. Он был не новый, и свежие драйверы к нему давно не выпускали. У меня была установлена последняя версия с WU. Поэтому я с легким сердцем удалил адаптер из диспетчера устройств, добавил снова, и все наладилось.
Повод для рассказа появился, когда спустя какое-то время проблема повторилась. Я воткнул кабель Ethernet, но скорость исходящего соединения осталась низкой. Отключился от Wi-Fi – скорость поднялась к ожидаемым 90+ Мбит/с.
Получается, при подключении одновременно к Ethernet и Wi-Fi система использовала беспроводное соединение с возродившейся проблемой.
На каждом заборе написано, что в Windows проводное подключение имеет приоритет над беспроводным. Другими словами, если вы одновременно подключены к Ethernet и Wi-Fi, в Интернет вы будет ходить по проводу.
У меня все было наоборот, и тут стоит достать из коробки еще один фрагмент пазла, который я держал в уме, но пока не пытался пристроить в картину.
Виртуальные коммутаторы
У меня виртуальные машины крутятся на Hyper-V, а в сеть ходят через созданный виртуальный коммутатор. Поскольку ноутбук почти всегда был подключен только к Wi-Fi, виртуальный коммутатор я создавал на основе адаптера беспроводной сети. Появившийся позже в 1709 «коммутатор по умолчанию» я не использовал.
Когда я удалил беспроводной адаптер из диспетчера устройств, мой виртуальный коммутатор исчез, но я заметил это не сразу, а только спустя некоторое время при следующем включении ВМ – в ней не было сети.
Я создал виртуальный коммутатор заново, но измерить скорость исходящих подключений в тот момент мне в голову не пришло. Лишь напоровшись на проблему снова, я назначил Hyper-V главным подозреваемым.
Дело в том, что хост использует виртуальный сетевой адаптер vEthernet для подключения к сети. Даже если виртуальный коммутатор Hyper-V основан на беспроводном адаптере, подключение к vEthernet считается проводным.
Это не вполне очевидно, хотя название адаптера намекает 
Приоритет маршрутов
При этом у меня подключение по vEthernet преобладало над обычным проводным подключением Ethernet. Сам я приоритеты не менял, но на всякий случай убедился в этом.
Приоритет маршрута определяется метрикой, и в дополнительных параметрах IPv4 сетевого адаптера можно посмотреть, задается ли она автоматически (и указать значение, если нужно). Но давайте перейдем в командную строку.
Настройка приоритетa для сетевых интерфейсов
Из вывода всех команд я убрал лишнее, чтобы сфокусироваться на проблеме, а английский – язык моей ОС.
Команда ipconfig /all выводит список сетевых адаптеров и их IP-адреса.
ipconfig /all Ethernet adapter Ethernet: Description . . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection IPv4 Address. . . . . . . . . . . : 192.168.1.149(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Ethernet adapter vEthernet (Wi-Fi): Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter IPv4 Address. . . . . . . . . . . : 192.168.1.211(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Ethernet adapter vEthernet (Default Switch): Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2 IPv4 Address. . . . . . . . . . . : 192.168.70.17(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.240
Сводку по сетевым интерфейсам выдает команда netstat -rn | more.
netstat -rn | more ===========================================================================
Interface List
4...3c 97 0e ce b8 41 ......Intel(R) 82579LM Gigabit Network Connection
32...a4 4e 31 94 9a 28 ......Hyper-V Virtual Ethernet Adapter
22...a4 4e 31 94 9a 29 ......Microsoft Wi-Fi Direct Virtual Adapter #4
10...a6 4e 31 94 9a 28 ......Microsoft Wi-Fi Direct Virtual Adapter #5
9...3c 77 e6 ed 0d 46 ......Bluetooth Device (Personal Area Network)
1...........................Software Loopback Interface 1
64...00 15 5d 18 c5 02 ......Hyper-V Virtual Ethernet Adapter #2
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.211 10
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.149 20
===========================================================================
В первом блоке можно определить приоритет сетевого интерфейса по номеру слева – чем меньше номер, тем выше приоритет. Значение метрики для интерфейса отображается во втором блоке – таблице маршрутов IPv4.
В результатах команд видно, что маршрут через виртуальный адаптер 192.168.1.211 преобладает над проводным 192.168.1.149.
Раз уж я был в консоли с правами администратора, то задал метрики для каждого интерфейса на месте. Сначала вывел их список, чтобы получить имена:
netsh interface show interface Admin State State Type Interface Name ------------------------------------------------------------------------- Enabled Connected Dedicated Wi-Fi Enabled Connected Dedicated Local Area Connection* 3 Enabled Connected Dedicated vEthernet (Wi-Fi) Enabled Connected Dedicated Network Bridge Enabled Connected Dedicated Ethernet Enabled Connected Dedicated vEthernet (Default Switch)
Затем указал метрики, поменяв значения местами:
netsh interface IP set interface interface="Ethernet" metric=10 netsh interface IP set interface interface="vEthernet (Wi-Fi)" metric=20
Теперь, подключив одновременно Ethernet и Wi-Fi, я убедился в высокой скорости исходящего соединения. Проводное соединение получило приоритет, но проблему низкой скорости по Wi-Fi это не решало, конечно.
Второй этап диагностики
В настройках Hyper-V я удалил попавший под подозрение коммутатор, что убрало связь между адаптером Wi-Fi и виртуальным адаптером Hyper-V. Без лишней прокладки адаптер беспроводной сети работал как положено – скорость исходящего соединения пришла в норму.
Я пообщался с Денисом Дягилевым, и он, в принципе, задал верное направление диагностики – параметры Virtual Machine Queue (VMQ). Однако такой настройки в настройках адаптера у меня не нашлось.
Решение
Первой мыслью было занести баг в Feedback Hub, но сначала положено искать, чтобы не плодить дубликатов. По запросу hyper- v switch нашлось описание моей проблемы, а заодно и обходной путь – отключение параметра Large Send Offload Version 2 (IPv4) в параметрах виртуального адаптера Hyper-V.
Эти же сведения можно посмотреть в PowerShell:
Get-NetAdapterAdvancedProperty -Name vEthernet* | ? DisplayName -like 'Large Send Offload*' | ft -wrap
Name DisplayName DisplayValue RegistryKeyword RegistryValue
---- ----------- ------------ --------------- -------------
vEthernet (Wi-Fi) Large Send Offload Version 2 Enabled *LsoV2IPv4 {1}
(IPv4)
vEthernet (Wi-Fi) Large Send Offload Version 2 Enabled *LsoV2IPv6 {1}
(IPv6)
и поменять значение, не покидая консоль:
Get-NetAdapterAdvancedProperty -Name vEthernet* | ? DisplayName -like 'Large Send Offload*v4*' | Set-NetAdapterAdvancedProperty -DisplayValue "Disabled"
Изменив настройки адаптера, я заново создал виртуальный коммутатор и проверил скорость – все наладилось.
Конец квеста!
Заключение
Эта история произошла в 2018 году. Регрессия возникла в Windows 10 1809. Поскольку основная система у меня была в кольце Release Preview (RP), я напоролся на проблему еще до того, как сборку отозвали. Дефект устранили в декабре 2018 года накопительным обновлением KB4469342, первом после перевыпуска 1809. Мне в RP оно пришло чуть раньше, я протестировал и отписался в комментариях к статье о белках-истеричках.
Я писал материал по горячим следам, но Денис Дягилев подал идею протестировать пользу параметра Large Send Offload в практических сценариях. Времени на это я так и не нашел. А когда Microsoft устранила проблему, публикация вроде бы стала неактуальной. И я замариновал статью в черновиках – почти на 5 лет 🤷♂️
Однако за эти годы вопросы приоритета сетевых интерфейсов и особенно параметра Large Send Offload обсуждалась в чате неоднократно. И каждый раз я сетовал, что не выпустил статью в свет. На прошлой неделе тема LSO вновь всплыла 🍑🔥 со вполне современным сетевым адаптером, что окончательно убедило меня выложить материал в блог.
Бонус: о приоритете сетевых интерфейсов (когда метрики не помогают)
Иногда желаемого результата не удается достичь, меняя метрики маршрутов. Все равно LAN имеет приоритет над Mobile broadband, а Bluetooth PAN над WWAN (внезапно). В таких случаях должна помочь групповая политика, о которой я написал в канале.