Вложенная виртуализация в Hyper V или Nested Virtualization доступна с редакций Windows Server 2016 и Windows 10. Грубо говоря это возможность виртуализировать Hyper V внутри Hyper V. Для настройки этой возможности нужно будет выполнить несколько команд Powershell. Кроме этого процессор должен быть Intel.
Установка ESXI на Hyper V, что тоже относится к вложенной виртуализации, у меня получалось, но ошибками и в конце концов я стал запускать Hyper V и ESXI поверх VMWare Workstation. Работать вместе Hyper V и VMWare Workstation тоже не могут. Опыт включения вложенной виртуализации для других платформ у меня отсутствует.
Первое с чем мы столкнемся при попытке включения или установки роли Hyper V во вложенном варианте это отсутствие возможности поставить галочку в GUI. Можно будет установить только консоль для управления. Эту ситуацию можно обойти установив Hyper V через Powershell, но и там мы встретим ошибку:
- Не удалось запустить виртуальную машину так как не работает один из компонентов Hyper-V
- Hyper-V cannot be installed: the processor does not have required virtualization capabilities
Первое что нужно сделать это выключить виртуальную машину. Я предпочитаю делать это через Powershell:
Stop-VM -Name 'Win10'
# или
Stop-Computer -ComputerName 'Win10'Далее нам нужно включить расширение Hyper-V:
Set-VMProcessor -VMName 'Win10' -ExposeVirtualizationExtensions $trueЕсли у вас появится какая-то ошибка это может значить, что виртуальная машина была импортирована и имеет старую версию. В этом случае можно обновить виртуальную машину Hyper-V:
Update-VMVersion -Name 'Win10'Для нормальной работы сети нам нужно включить MAC spoofing:
Get-VMNetworkAdapter -VMName 'Win10' | Set-VMNetworkAdapter -MacAddressSpoofing OnЛибо через интерфейс:
Остальные ограничения связанные с Nested Virtualization, которые не получиться использовать:
- Динамическая память
- Изменение памяти работающей VM
Были проблемы с сетевыми адаптерами. При попытках настроить Docker на VM никак не работала сеть и в таких случаях помогала переустановка драйвера на сетевом адаптере основной ОС. Это происходило на Windows 10.
…
Теги:
#hyper-v
Пользователи ПК могут использовать функцию вложенной виртуализации для запуска Hyper-V внутри виртуальной машины Hyper-V (ВМ) на хост-компьютере с Windows 11 или Windows 10. Это полезно для запуска эмулятора телефона Visual Studio на виртуальной машине или тестирования конфигураций, для которых обычно требуется несколько хостов. В этом посте мы покажем вам, как включить или отключить вложенную виртуализацию для виртуальных машин в Hyper-V.
Вложенная виртуализация поддерживается как в Azure, так и в локальной среде со следующими предварительными требованиями.
Процессор Intel с технологией VT-x и EPT
- Хост Hyper-V должен быть Windows Server 2016/Windows 10 или более поздней версии.
- Конфигурация ВМ версии 8.0 или выше
Процессор AMD EPYC/Ryzen или новее
- Хост Hyper-V должен быть Windows Server 2022/Windows 11 или более поздней версии.
- Конфигурация ВМ версии 10.0 или выше
В обеих конфигурациях гостем может быть любая гостевая операционная система, поддерживаемая Windows. Имейте в виду, что более новые операционные системы Windows могут поддерживать просветления, повышающие производительность.
Включить вложенную виртуализацию
Чтобы включить вложенную виртуализацию для виртуальных машин в Hyper-V, сделайте следующее:
- Создайте виртуальную машину, используя указанные выше предварительные условия.
- Пока виртуальная машина находится в выключенном состоянии, на физическом узле Windows Hyper-V откройте PowerShell в режиме с повышенными привилегиями.
- В консоли PowerShell выполните приведенную ниже команду, чтобы включить вложенную виртуализацию для виртуальной машины. Замените <имяВМ> местозаполнитель с фактическим именем виртуальной машины для виртуальной машины, которую вы создали ранее.
Set-VMProcessor -VMName -ExposeVirtualizationExtensions $true
Отключить вложенную виртуализацию
Вы можете отключить вложенную виртуализацию для остановленной виртуальной машины. Чтобы отключить вложенную виртуализацию для виртуальных машин в Hyper-V, сделайте следующее:
- Откройте PowerShell в режиме с повышенными привилегиями на физическом узле Windows Hyper-V.
- В консоли PowerShell выполните следующую команду:
Set-VMProcessor -VMName -ExposeVirtualizationExtensions $false
- Выйдите из PowerShell после выполнения команды.
Вот и все о том, как включить или отключить вложенную виртуализацию для виртуальных машин в Hyper-V!
Зачем вам использовать вложенную виртуализацию?
Наиболее заметным преимуществом вложенной виртуализации является повышенная гибкость. Это возможность размещать виртуальные среды внутри виртуальных сред, что позволяет вам разрабатывать и тестировать программное обеспечение на ваших собственных условиях и предоставляет вам гибкие среды-песочницы, которые вы можете адаптировать к своим потребностям.
Что необходимо отключить для реализации вложенной виртуализации?
Только процессоры Intel с технологиями VT-x и EPT поддерживают вложенную виртуализацию. Процессоры AMD в настоящее время не поддерживают вложенную виртуализацию. Кроме того, должно быть достаточно физической памяти для запуска виртуальных машин, и виртуальная машина не может использовать динамическую память.
Как включить вложенную виртуализацию на виртуальной машине Azure?
Чтобы включить вложенную виртуализацию, необходимо выполнить следующие задачи:
- Включите роль Hyper-V. Роль Hyper-V должна быть включена для создания и запуска виртуальных машин Hyper-V на виртуальной машине Lab Services.
- Включить DHCP.
- Создайте сеть NAT для виртуальных машин Hyper-V.
Какой размер виртуальной машины Azure поддерживает вложенную виртуализацию?
Теперь вы можете включить вложенную виртуализацию, используя размеры виртуальных машин Dv3 и Ev3. Использование возможности вложенной виртуализации Azure позволяет запускать виртуальную машину внутри виртуальной машины — виртуальная машина Windows Server может быть развернута в Azure и запускать вложенные виртуальные машины формата Hyper-V. В этой среде вы можете реплицировать локальные виртуальные машины Hyper-V в Azure.
| title | description | keywords | author | ms.author | ms.date | ms.topic | ms.prod | ms.assetid |
|---|---|---|---|---|---|---|---|---|
|
Run Hyper-V in a Virtual Machine with Nested Virtualization |
Learn about how to use nested virtualization to run Hyper-V in a virtual machine to emulate configurations that normally require multiple hosts. |
windows 10, hyper-v |
johncslack |
mabrigg |
9/9/2021 |
article |
windows-10-hyperv |
68c65445-ce13-40c9-b516-57ded76c1b15 |
Run Hyper-V in a Virtual Machine with Nested Virtualization
Nested virtualization is a feature that allows you to run Hyper-V inside of a Hyper-V virtual machine (VM). This is helpful for running a Visual Studio phone emulator in a virtual machine, or testing configurations that ordinarily require several hosts.
[!NOTE]
Nested Virtualization is supported both Azure and on-premises. However, if using a non-Microsoft hypervisor such as KVM, Microsoft can not provide end-to-end support please ensure your vendor supports this scenario.
Prerequisites
Intel processor with VT-x and EPT technology
- The Hyper-V host must be Windows Server 2016/Windows 10 or greater
- VM configuration version 8.0 or greater
AMD EPYC/Ryzen processor or later
- The Hyper-V host must be Windows Server 2022/Windows 11 or greater
- VM configuration version 10.0 or greater
[!NOTE]
The guest can be any Windows supported guest operating system. Newer Windows operating systems may support enlightenments that improve performance.
Configure Nested Virtualization
- Create a virtual machine. See the prerequisites above for the required OS and VM versions.
- While the virtual machine is in the OFF state, run the following command on the physical Hyper-V host. This enables nested virtualization for the virtual machine.
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
- Start the virtual machine.
- Install Hyper-V within the virtual machine, just like you would for a physical server. For more information on installing Hyper-V see, Install Hyper-V.
You can disable nested virtualization for a stopped virtual machine using the following PowerShell command:
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $false
Dynamic Memory and Runtime Memory Resize
When Hyper-V is running inside a virtual machine, the virtual machine must be turned off to adjust its memory. This means that even if dynamic memory is enabled, the amount of memory will not fluctuate. For virtual machines without dynamic memory enabled, any attempt to adjust the amount of memory while it’s on will fail.
Note that simply enabling nested virtualization will have no effect on dynamic memory or runtime memory resize. The incompatibility only occurs while Hyper-V is running in the VM.
Networking Options
There are two options for networking with nested virtual machines:
- MAC address spoofing
- NAT networking
MAC Address Spoofing
In order for network packets to be routed through two virtual switches, MAC address spoofing must be enabled on the first (L1) level of virtual switch. This is completed with the following PowerShell command.
Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter -MacAddressSpoofing On
Network Address Translation (NAT)
The second option relies on network address translation (NAT). This approach is best suited for cases where MAC address spoofing is not possible, like in a public cloud environment.
First, a virtual NAT switch must be created in the host virtual machine (the «middle» VM). Note that the IP addresses are just an example, and will vary across environments:
New-VMSwitch -Name VmNAT -SwitchType Internal New-NetNat –Name LocalNAT –InternalIPInterfaceAddressPrefix “192.168.100.0/24”
Next, assign an IP address to the net adapter:
Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress 192.168.100.1 -AddressFamily IPv4 -PrefixLength 24
Each nested virtual machine must have an IP address and gateway assigned to it. Note that the gateway IP must point to the NAT adapter from the previous step. You may also want to assign a DNS server:
Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress 192.168.100.2 -DefaultGateway 192.168.100.1 -AddressFamily IPv4 -PrefixLength 24 Netsh interface ip add dnsserver “vEthernet (VmNat)” address=<my DNS server>
How nested virtualization works
Modern processors include hardware features that make virtualization faster and more secure. Hyper-V relies on these processor extensions to run virtual machines (e.g. Intel VT-x and AMD-V). Typically, once Hyper-V starts, it prevents other software from using these processor capabilities. This prevents guest virtual machines from running Hyper-V.
Nested virtualization makes this hardware support available to guest virtual machines.
The diagram below shows Hyper-V without nesting. The Hyper-V hypervisor takes full control of the hardware virtualization capabilities (orange arrow), and does not expose them to the guest operating system.
In contrast, the diagram below shows Hyper-V with nested virtualization enabled. In this case, Hyper-V exposes the hardware virtualization extensions to its virtual machines. With nesting enabled, a guest virtual machine can install its own hypervisor and run its own guest VMs.
3rd Party Virtualization Apps
Virtualization applications other than Hyper-V are not supported in Hyper-V virtual machines, and are likely to fail. This includes any software that requires hardware virtualization extensions.
| title | description | keywords | author | ms.author | ms.date | ms.topic | ms.prod | ms.assetid |
|---|---|---|---|---|---|---|---|---|
|
Run Hyper-V in a Virtual Machine with Nested Virtualization |
Learn about how to use nested virtualization to run Hyper-V in a virtual machine to emulate configurations that normally require multiple hosts. |
windows 10, hyper-v |
johncslack |
mabrigg |
9/9/2021 |
article |
windows-10-hyperv |
68c65445-ce13-40c9-b516-57ded76c1b15 |
Run Hyper-V in a Virtual Machine with Nested Virtualization
Nested virtualization is a feature that allows you to run Hyper-V inside of a Hyper-V virtual machine (VM). This is helpful for running a Visual Studio phone emulator in a virtual machine, or testing configurations that ordinarily require several hosts.
[!NOTE]
Nested Virtualization is supported both Azure and on-premises. However, if using a non-Microsoft hypervisor such as KVM, Microsoft can not provide end-to-end support please ensure your vendor supports this scenario.
Prerequisites
Intel processor with VT-x and EPT technology
- The Hyper-V host must be Windows Server 2016/Windows 10 or greater
- VM configuration version 8.0 or greater
AMD EPYC/Ryzen processor or later
- The Hyper-V host must be Windows Server 2022/Windows 11 or greater
- VM configuration version 10.0 or greater
[!NOTE]
The guest can be any Windows supported guest operating system. Newer Windows operating systems may support enlightenments that improve performance.
Configure Nested Virtualization
- Create a virtual machine. See the prerequisites above for the required OS and VM versions.
- While the virtual machine is in the OFF state, run the following command on the physical Hyper-V host. This enables nested virtualization for the virtual machine.
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
- Start the virtual machine.
- Install Hyper-V within the virtual machine, just like you would for a physical server. For more information on installing Hyper-V see, Install Hyper-V.
You can disable nested virtualization for a stopped virtual machine using the following PowerShell command:
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $false
Dynamic Memory and Runtime Memory Resize
When Hyper-V is running inside a virtual machine, the virtual machine must be turned off to adjust its memory. This means that even if dynamic memory is enabled, the amount of memory will not fluctuate. For virtual machines without dynamic memory enabled, any attempt to adjust the amount of memory while it’s on will fail.
Note that simply enabling nested virtualization will have no effect on dynamic memory or runtime memory resize. The incompatibility only occurs while Hyper-V is running in the VM.
Networking Options
There are two options for networking with nested virtual machines:
- MAC address spoofing
- NAT networking
MAC Address Spoofing
In order for network packets to be routed through two virtual switches, MAC address spoofing must be enabled on the first (L1) level of virtual switch. This is completed with the following PowerShell command.
Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter -MacAddressSpoofing On
Network Address Translation (NAT)
The second option relies on network address translation (NAT). This approach is best suited for cases where MAC address spoofing is not possible, like in a public cloud environment.
First, a virtual NAT switch must be created in the host virtual machine (the «middle» VM). Note that the IP addresses are just an example, and will vary across environments:
New-VMSwitch -Name VmNAT -SwitchType Internal New-NetNat –Name LocalNAT –InternalIPInterfaceAddressPrefix “192.168.100.0/24”
Next, assign an IP address to the net adapter:
Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress 192.168.100.1 -AddressFamily IPv4 -PrefixLength 24
Each nested virtual machine must have an IP address and gateway assigned to it. Note that the gateway IP must point to the NAT adapter from the previous step. You may also want to assign a DNS server:
Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress 192.168.100.2 -DefaultGateway 192.168.100.1 -AddressFamily IPv4 -PrefixLength 24 Netsh interface ip add dnsserver “vEthernet (VmNat)” address=<my DNS server>
How nested virtualization works
Modern processors include hardware features that make virtualization faster and more secure. Hyper-V relies on these processor extensions to run virtual machines (e.g. Intel VT-x and AMD-V). Typically, once Hyper-V starts, it prevents other software from using these processor capabilities. This prevents guest virtual machines from running Hyper-V.
Nested virtualization makes this hardware support available to guest virtual machines.
The diagram below shows Hyper-V without nesting. The Hyper-V hypervisor takes full control of the hardware virtualization capabilities (orange arrow), and does not expose them to the guest operating system.
In contrast, the diagram below shows Hyper-V with nested virtualization enabled. In this case, Hyper-V exposes the hardware virtualization extensions to its virtual machines. With nesting enabled, a guest virtual machine can install its own hypervisor and run its own guest VMs.
3rd Party Virtualization Apps
Virtualization applications other than Hyper-V are not supported in Hyper-V virtual machines, and are likely to fail. This includes any software that requires hardware virtualization extensions.
Вложенная виртуализация (Nested Virtualization) позволяет запустить Hyper-V внутри виртуальной машины и создать в таком гипервизоре Hyper-V еще несколько виртуальных машин. Чаще всего вложенная виртуализация используется в различных стендах, лабах и тестовых средах.
Microsoft Hyper-V поддерживает вложенную виртуализацию начиная с Windows Server 2016. Если попытаться установить роль Hyper-V внутри ВМ на гостевом Hyper-V с Windows Server 2012 R2, вы получите ошибку:
Hyper-V can not be installed: The hypervisor is already running.
Эта ошибка связана с тем что хостовой Hyper-V специально маскировал от гостевых ОС наборы аппаратных инструкций (Virtualization Extensions) Intel VT-x и AMD-V.
В Windows Server 2016 архитектура Hyper-V была изменена. Изменились и требования к процессорам. Теперь для работы вложенной виртуализации кроме поддержки Intel VT-x, процессор должен поддерживать Intel EPT (предоставляет виртуальным машинам прямой доступ к памяти, минуя гипервизор).
Другие ограничения при использовании вложенной виртуализации:
- В хостовой и гостевой Hyper-V должны быть установлены Windows Server 2016 или Windows 10 с ролью Hyper-V;
- Версия виртуального оборудования Hyper-V (VM hardware version) 8.0 и выше;
- Для виртуальных машин, запушенных во вложенной виртуализации не поддерживается динамическая память, динамическая миграция, снимки ВМ и состояние Save/Restore.
Рассмотрим, как включить и использовать вложенную виртуализацию в Windows Server 2016.
Прежде всего вам нужно обновить версию конфигурации ВМ Hyper-V для которой вы хотите включить вложенную виртуализацию до версии 8.0 или выше (виртуальная машина должна быть выключена). Для этого запустите консоль Hyper-V Manager, найдите ВМ, щелкните по ней правой кнопкой и выберите Upgrade Configuration Version.
Также вы можете обновить HW версию виртуальной машины через PowerShell:
Update-VMVersion -Name ‘WinSrv2016Test’
Вы можете обновить версию виртуального оборудования сразу для всех ВМ на хосте:
Get-VM | Update-VMVersion
Теперь для выбранной виртуальной машины нужно включить поддержку вложенной виртуализации. По умолчанию гипервизор маскирует от гостевых ОС аппаратные наборы инструкций, отвечающих за виртуализацию. Чтобы исправить это, воспользуйтесь командой:
Set-VMProcessor -VMName VMName -ExposeVirtualizationExtensions $true
Т.к. для вложенных Hyper-V не поддерживается динамическая память, вы должны отключить эту опцию в настройках ВМ (VM -> Settings -> Memory -> снимите чекбокс Enable Dynamic Memory).
Или вы можете отключить динамическую память через PowerShell:
Set-VMMemory 'WinSrv2016Nested' -DynamicMemoryEnabled $false
Если вы планируете предоставлять доступ вложенным виртуальным машинам во внешнюю сеть, хостовой Hyper-V может увидеть несколько MAC адресов на единственном сетевом адаптере виртуальной машины. Поэтому вам нужно разрешить спуфинг MAC-адресов для сетевого адаптера ВМ.
Откройте свойства ВМ в консоли Hyper-V, найдите сетевой адаптер ВМ и в секции Advanced features включите опцию Enable MAC address spoofing.
Также вы можете включить эту опцию через PowerShell:
Get-VMNetworkAdapter -VMName 'WinSrv2016Test' | Set-VMNetworkAdapter -MacAddressSpoofing On
Для быстрой проверки ВМ и включения динамической памяти вы можете использовать готовый скрипт Enable-NestedVm.ps1.
Invoke-WebRequest https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-tools/Nested/Enable-NestedVm.ps1 -OutFile ~/Enable-NestedVm.ps1 ~/Enable-NestedVm.ps1 -VmName 'WinSrv2016Test'
Теперь вам осталось установить роль Hyper-V в виртуальной машине (Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart) и вы можете создавать вложенные виртуальные машины.
Ни для кого не секрет, что в Windows Server 2016 появилась вложенная виртуализация Hyper-V. Несмотря на то, что на момент написания статьи доступна лишь версия Technical Preview 5, уже в ней можно очень близко познакомиться с новым функционалом, о котором я и постараюсь коротко рассказать в этой статье.
Хочу отметить, что все сказанное относится к предрелизной версии и может сильно отличаться от официального релиза.
Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.
Содержание
- 1 Вложенная виртуализация Hyper-V
- 1.1 Архитектура
- 1.2 Ограничения
- 1.2.1 Аппаратные
- 1.2.2 Программные
- 1.3 Применение
- 1.4 Настройка
- 1.4.1 Обновление версии VM
- 1.4.2 Активирование вложенной виртуализации
- 1.4.3 Спуфинг MAC-адресов / NAT
- 1.4.4 Отключение динамической памяти
Функция вложенной виртуализации в гипервизорах разных производителей доступна достаточно давно. Например у VMWare поддержка 64х-битных вложенных виртуальных машин была реализована в версии ESXi 5.1 и это было аж в 2011 году, не говоря о поддержке 32х-битных вложенных ОС, доступных ещё ранее. Другие вендоры также не отставали. Тем не менее, у Microsoft мы не могли увидеть такого функционала до сегодняшнего дня. Почему? Официального ответа мне найти не удалось, но можно говорить как об общей позиции (неприоритетная на то время задача), так и о чисто логических рассуждениях — в 2008 году с выходом Windows Server 2008 и последующей 2008 R2 говорить о вложенной виртуализации было не совсем актуально, ведь гипервизор был ещё во многом сыроват по многим направлениям (например max. vCPU упиралось в 4 шт.), а ситуация с конкурентами была такова, что Microsoft по сути вынужден был активно их догонять.
Архитектура
Классическая виртуализация первого типа представляет из себя гипервизор, разграничивающий доступ к оборудованию между единственным родительским и множеством гостевых разделов. При этом доступен только один уровень виртуализации — Level 1 — и использование вложенных виртуальных машин (VM внутри VM) не подразумевается. В общем виде архитектура выглядит следующим образом 1:
Раньше попытка развернуть роль Hyper-V внутри виртуальной машины непременно заканчивалась ошибкой:
Так происходило потому, что гипервизор намеренно маскировал от гостевых ОС наборы аппаратных инструкций (Virtualization Extensions), отвечающих за виртуализацию 2 — Intel VT-x и AMD-V (все мы помним, что Hyper-V — это система именно аппаратной виртуализации и без поддержки функционала со стороны «железа» работать не будет).
Теперь же архитектура изменилась таким образом, что появилась возможность передачи наборов аппаратных инструкций в гостевые ОС (по умолчанию этот функционал отключен):
Все это открывает возможности для вложенной виртуализации, которая при этом не ограничена вторым уровнем (Level 2 на рис. вверху).
Примечание: в лабораторных условиях я совершенно спокойной развернул виртуальную машину с четвертой степенью вложенности.
Но как и у любой свежей технологии (в данном случае свежей именно для Microsoft), у неё есть некоторые ограничения, о которых ниже.
Ограничения
Условно можно разделить на аппаратные и программные.
Аппаратные
Аппаратные ограничения упираются в обязательную поддержку процессором Intel технологий VT-x 3 и EPT. Если наличие VT-x было стандартным требованиям и для ранних версий Hyper-V, то необходимость в EPT появилась только сейчас и только для вложенной виртуализации 4:
Примечание: Intel EPT предоставляет виртуальным машинам прямой доступ к памяти, минуя гипервизор 5 и по сути представляет из себя технологию виртуализации страниц памяти. Технология эта не нова и её можно встретить даже в давно устаревших Core 2 Quad.
И я ничего не забыл, не написав про процессоры AMD. Дело в том, что в Windows Server 2016 TP5 вложенная виртуализация на процессорах AMD пока что не поддерживается.
Программные
Программных ограничений значительно больше:
- Использование Windows Server 2016 или Windows 10 как в родительском, так и в гостевых разделах;
- Виртуальная машина с версией конфигурации 8.0 и выше;
Примечание: в Windows Server 2016 изменился формат хранения файлов конфигурации виртуальных машин 6. Если верить разработчикам, то новый формат стал более надежным, также появилась поддержка новых функций, которые будут недоступны при использовании виртуальных машин со старой версией конфигурации (для Windows Server 2012 R2 эта версия — 5.0).
Для вложенных виртуальных машин не поддерживается:
- Динамическая память;
- Динамическая миграция;
- Снимки виртуальных машин и состояния Save/Restore;
Важно помнить, что если вы собрались выпускать вложенные виртуальные машины во внешнюю сеть, то на виртуальном адаптере «хостовой» виртуальной машины будет поднят виртуальный свитч и на нем будут несколько виртуальных сетевых адаптеров, а значит несколько MAC-адресов, а значит надо включать спуфинг MAC-адресов на адаптере. Это тоже в некотором смысле ограничение.
Есть и обходной вариант — использовать NAT (это тоже новый функционал, о котором расскажу ниже).
Применение
У тех, кто встретился с вложенной виртуализацией впервые, может возникнуть вопрос об области её применения. Остановимся на этом более подробно.
Наиболее адекватными сценариями представляются тестирование и разработка. В продакшене вы конечно можете использовать полностью вложенную виртуальную инфраструктуру, но непременно столкнетесь с падением производительности вложенных экземпляров.
Мне стало интересно проверить на реальной среде падение производительности ЦП внутри виртуальных машин разной степени вложенности. Для этого я использовал Hot CPU Tester Pro. Хоть и тестирование получилось исключительно субъективное, но оно как минимум намекает на существенное падение отдачи CPU:
Примечание: для измерения индекса производительности ЦП я просто запускал тест по очереди сначала на хосте (при этом все VM были заглушены), потом включал виртуальную машину и измерял индекс внутри неё, выделив максимально возможное количество vCPU. Следующим шагом был запуск VM внутри этой VM и измерение индекса производительности уже внутри виртуальной машины второй вложенности и т.д.
Моего терпения хватило только для развертывания экземпляра третьей вложенности.
Настройка
Для возможности использовать вложенную виртуализацию, необходимо выполнить ряд настроек на хостовой ОС. Приступаем.
Обновление версии VM
Если по каким-либо причинам ваша виртуальная машина имеет версию конфигурации ниже 7.1 (например она смигрировала на ваш Hyper-V с предыдущих версий Technical Preview), то обязательно обновляем конфигурацию вручную, нажав правой кнопкой по VM и выбрав Обновить версию конфигурации:
Или через Powershell:
|
Update-VMVersion -Name «vm_name» |
Последний вариант удобен при массовом обновлении виртуальных машин. Обновить все VM враз можно командой Get-VM | Update-VMVersion.
Активирование вложенной виртуализации
По умолчанию гипервизор все также маскирует аппаратные наборы инструкций, отвечающих за виртуализацию, не передавая их гостевым ОС, как я и упоминал ранее. Чтобы изменить это поведение, необходимо выполнить команду:
|
Set—VMProcessor —VMName VMName —ExposeVirtualizationExtensions $true |
Изменение опции ExposeVirtualizationExtensions доступно только через Powershell.
Спуфинг MAC-адресов / NAT
Если вы планируете настроить сеть вложенных виртуальных машин таким образом, чтобы все они находились в реальной локальной сети, то на одном единственном сетевом адаптере «хостовой» виртуальной машины будут висеть несколько MAC-адресов. Это ожидаемо вызовет проблемы со связью, если не активирована настройка Включить спуфинг MAC-адресов (а она не активирована по умолчанию).
Ставим галочку вручную:
Или через Powershell:
|
Get—VMNetworkAdapter —VMName «vm_name» | Set—VMNetworkAdapter —MacAddressSpoofing On |
Если же вы не планируете выпускать вложенные VM в локальную сеть, но все же хотите обеспечить их возможностью коммуникаций по сети, можно поднять NAT 7. Для этого необходимо создать виртуальный коммутатор внутреннего типа командой (на данный момент настройка NAT возможна только через Powershell):
Примечание: если до этого момента все настройки производились на хостовой ОС, то NAT настраивать нужно внутри виртуальной машины.
|
New—VMSwitch —Name «NAT 01» —SwitchType Internal |
Создаем NAT:
|
New—NetNat —Name «name» –InternalIPInterfaceAddressPrefix ‘ip-address/netmask’ |
Обратите внимание, что на этом этапе нужно определиться с подсетью, которая будет использоваться за NAT-ом. Разумеется диапазон адресов не должен пересекаться с реальными диапазонами в вашей локальной сети.
Назначаем адрес для интерфейса:
|
Get-NetAdapter «name» | New-NetIPAddress -IPAddress ip_address -AddressFamily IPv4 -PrefixLength number |
На этом шаге внутреннему интерфейсу нужно присвоить адрес, который будет использоваться вложенными виртуальными машинами как шлюз. Конструкция команд, используемая на скриншоте выше, совсем необязательна, вы можете обойтись и без Get-NetAdapter 8, указав командлету New-NetIPAddress 9 индекс сетевого интерфейса (поле ifIndex). В этом случае моя команда выглядела бы таким образом: New-NetIPAddress -IPAddress 172.16.0.1 -AddressFamily IPv4 -PrefixLength 24 -InterfaceIndex 9.
Ну а теперь дело за малым: сконфигурируем сеть на вложенной виртуальной машине:
И проверим связь с внешним миром:
Переходим к последнему этапу.
Отключение динамической памяти
Динамическая память для виртуальных машин, внутри которых будет развернута роль Hyper-V, не поддерживается, а потому позоботьтесь о том, чтобы она была полностью отключена. Сделать это можно через консоль Hyper-V:
Или через Powershell командой:
|
Set-VMMemory «vm_name» -DynamicMemoryEnabled $false |
На этом базовая подготовка виртуальной машины для использования вложенной виртуализации завершена и можно переходить к установке роли Hyper-V внутри VM. Этот процесс ничуть не отличается от обычной подготовки хоста, поэтому подробно рассматривать его я не собираюсь, только для большей убедительности покажу скриншот получившегося чуда:
Разумеется все те настройки, которые вы проводили на хосте, чтобы запустить вложенные виртуалки, нужно выполнять и внутри самих виртуалок, если вы планируете использовать вложенную виртуализацию на них.
comments powered by HyperComments