Мы часто пишем о проблемах вложенной виртуализации (nested virtualization), которая представляет собой способ запустить виртуальные машины на гипервизоре, который сам установлен в виртуальной машине. На платформе VMware ESXi эта проблема давно решена, и там nested virtualization работает уже давно, мало того - для виртуального ESXi есть даже свои VMware Tools.
Как мы недавно писали, решения для вложенной виртуализации на платформе Microsoft Hyper-V не было. При попытке запустить виртуальную машину на виртуальном хосте Hyper-V администраторы получали вот такую ошибку:
VM failed to start. Failed to start the virtual machine because one of the Hyper-V components is not running.
Все это происходило из-за того, что Microsoft не хотела предоставлять виртуальным машинам средства эмуляции техник аппаратной виртуализации Intel VT и AMD-V. Стандартная схема виртуализации Hyper-V выглядела так:
Virtualization Extensions передавались только гипервизору хостовой ОС, но не гостевой ОС виртуальной машины. А без этих расширений виртуальные машины в гостевой ОС запущены быть не могли.
Соответственно, это позволит запустить вложенные виртуальные машины на хосте, который сам является виртуальной машиной с гостевой ОС Windows и включенной ролью Hyper-V.
На данный момент работает это только с Intel VT, но по идее к релизу Windows Server 2016 должно заработать и для AMD-V.
Сфера применения вложенных виртуальных машин не такая уж и узкая. Сейчас видится 2 основных направления:
Виртуальные тестовые лаборатории, где развертываются виртуальные серверы Hyper-V и строятся модели работающих виртуальных инфраструктур в рамках одного физического компьютера.
Использование контейнеризованных приложений (например, на движке Docker) в виртуальных машинах на виртуальных хостах Hyper-V. Более подробно о Windows Server Containers можно почитать вот тут. Немногим ранее мы писали об аналогичной архитектуре на базе VMware vSphere, анонсированной на VMware VMworld 2015.
Надо отметить, что для вложенных виртуальных машин не поддерживаются следующие операции (как минимум):
Dynamic Memory
Горячее изменение памяти работающей ВМ
Снапшоты
Live Migration
Операции save/restore
Ну и вообще, вряд ли вложенная виртуализация вообще когда-нибудь будет полностью поддерживаться в производственной среде. Кстати, вложенная виртуализация на сторонних гипервизорах (например, VMware vSphere) также не поддерживается.
Для того, чтобы вложенная виртуализация заработала, нужно:
1. Использовать Windows 10 Build 10565. Windows Server 2016 Technical Preview 3 (TPv3) и Windows 10 GA - не подойдут, так как в них возможности Nested Virtualization нет.
2. Включить Mac Spoofing на сетевом адаптере виртуального хоста Hyper-V, так как виртуальный коммутатор хостового Hyper-V будет видеть несколько MAC-адресов с этого виртуального адаптера.
3. В Windows 10 нужно отключить фичу Virtualization Based Security (VBS), которая предотвращает трансляцию Virtualization Extensions в виртуальные машины.
4. Предусмотреть память под сам гостевой гипервизор и под все запущенные виртуальные машины. Память для гипервизора можно рассчитать так:
Теперь для того чтобы включить Nested Virtualization, выполните следующий сценарий PowerShell (в нем и VBS отключается, и Mac Spoofing включается):
Далее создайте виртуальную машину на базе Windows 10 Build 10565, и включите в ней Mac Spoofing (если вы не сделали это в скрипте). Сделать это можно через настройки ВМ или следующей командой PowerShell:
Set-VMNetworkAdapter -VMName <VMName> -MacAddressSpoofing on
Ну а дальше просто запускайте виртуальную машину на виртуальном хосте Hyper-V: