Вложенная виртуализация Hyper-V в Windows Server 2016

Ни для кого не секрет, что в Windows Server 2016 появилась вложенная виртуализация Hyper-V. Несмотря на то, что на момент написания статьи доступна лишь версия Technical Preview 5, уже в ней можно очень близко познакомиться с новым функционалом, о котором я и постараюсь коротко рассказать в этой статье.

Хочу отметить, что все сказанное относится к предрелизной версии и может сильно отличаться от официального релиза.

---

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу  Windows Server  на моем блоге.

---

Вложенная виртуализация Hyper-V

Функция вложенной виртуализации в гипервизорах разных производителей доступна достаточно давно. Например у VMWare поддержка 64х-битных вложенных виртуальных машин была реализована в версии ESXi 5.1 и это было аж в 2011 году, не говоря о поддержке 32х-битных вложенных ОС, доступных ещё ранее. Другие вендоры также не отставали. Тем не менее, у Microsoft мы не могли увидеть такого функционала до сегодняшнего дня. Почему? Официального ответа мне найти не удалось, но можно говорить как об общей позиции (неприоритетная на то время задача), так и о чисто логических рассуждениях — в 2008 году с выходом Windows Server 2008 и последующей 2008 R2 говорить о вложенной виртуализации было не совсем актуально, ведь гипервизор был ещё во многом сыроват по многим направлениям (например max. vCPU упиралось в 4 шт.), а ситуация с конкурентами была такова, что Microsoft по сути вынужден был активно их догонять.

Архитектура

Классическая виртуализация первого типа представляет из себя гипервизор, разграничивающий доступ к оборудованию между единственным родительским и множеством гостевых разделов. При этом доступен только один уровень виртуализации — Level 1 — и использование вложенных виртуальных машин (VM внутри VM) не подразумевается. В общем виде архитектура выглядит следующим образом ¹:

Раньше попытка развернуть роль Hyper-V внутри виртуальной машины непременно заканчивалась ошибкой:

Так происходило потому, что гипервизор намеренно маскировал от гостевых ОС наборы аппаратных инструкций (Virtualization Extensions), отвечающих за виртуализацию ² — Intel VT-x и AMD-V (все мы помним, что Hyper-V — это система именно аппаратной виртуализации и без поддержки функционала со стороны «железа» работать не будет).

Теперь же архитектура изменилась таким образом, что появилась возможность передачи наборов аппаратных инструкций в гостевые ОС (по умолчанию этот функционал отключен):

Все это открывает возможности для вложенной виртуализации, которая при этом не ограничена вторым уровнем (Level 2 на рис. вверху).

Но как и у любой свежей технологии (в данном случае свежей именно для Microsoft), у неё есть некоторые ограничения, о которых ниже.

Ограничения

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

Аппаратные

Аппаратные ограничения упираются в обязательную поддержку процессором Intel технологий VT-x ³ и EPT. Если наличие VT-x было стандартным требованиям и для ранних версий Hyper-V, то необходимость в EPT появилась только сейчас и только для вложенной виртуализации ⁴:

И я ничего не забыл, не написав про процессоры AMD. Дело в том, что в Windows Server 2016 TP5 вложенная виртуализация на процессорах AMD пока что не поддерживается.

Программные

Программных ограничений значительно больше:

1. Использование Windows Server 2016 или Windows 10 как в родительском, так и в гостевых разделах;
2. Виртуальная машина с версией конфигурации 8.0 и выше;

Для вложенных виртуальных машин не поддерживается:

1. Динамическая память;
2. Динамическая миграция;
3. Снимки виртуальных машин и состояния Save/Restore;

Важно помнить, что если вы собрались выпускать вложенные виртуальные машины во внешнюю сеть, то на виртуальном адаптере «хостовой» виртуальной машины будет поднят виртуальный свитч и на нем будут несколько виртуальных сетевых адаптеров, а значит несколько MAC-адресов, а значит надо включать спуфинг MAC-адресов на адаптере.  Это тоже в некотором смысле ограничение.

Есть и обходной вариант — использовать NAT (это тоже новый функционал, о котором расскажу ниже).

Применение

У тех, кто встретился с вложенной виртуализацией впервые, может возникнуть вопрос об области её применения. Остановимся на этом более подробно.

Наиболее адекватными сценариями представляются тестирование и разработка. В продакшене вы конечно можете использовать полностью вложенную виртуальную инфраструктуру, но непременно столкнетесь с падением производительности вложенных экземпляров.

Мне стало интересно проверить на реальной среде падение производительности ЦП внутри виртуальных машин разной степени вложенности. Для этого я использовал Hot CPU Tester Pro. Хоть и тестирование получилось исключительно субъективное, но оно как минимум намекает на существенное падение отдачи CPU:

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

Настройка

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

Обновление версии VM

Если по каким-либо причинам ваша виртуальная машина имеет версию конфигурации ниже 7.1 (например она смигрировала на ваш Hyper-V с предыдущих версий Technical Preview), то обязательно обновляем конфигурацию вручную, нажав правой кнопкой по VM и выбрав Обновить версию конфигурации:

Или через Powershell:

Последний вариант удобен при массовом обновлении виртуальных машин. Обновить все VM враз можно командой Get-VM | Update-VMVersion.

Активирование вложенной виртуализации

По умолчанию гипервизор все также маскирует аппаратные наборы инструкций, отвечающих за виртуализацию, не передавая их гостевым ОС, как я и упоминал ранее. Чтобы изменить это поведение, необходимо выполнить команду:

Изменение опции ExposeVirtualizationExtensions доступно только через Powershell.

Спуфинг MAC-адресов / NAT

Если вы планируете настроить сеть вложенных виртуальных машин таким образом, чтобы все они находились в реальной локальной сети, то на одном единственном сетевом адаптере «хостовой» виртуальной машины будут висеть несколько MAC-адресов. Это ожидаемо вызовет проблемы со связью, если не активирована настройка Включить спуфинг MAC-адресов (а она не активирована по умолчанию).

Ставим галочку вручную:

Или через Powershell:

Если же вы не планируете выпускать вложенные VM в локальную сеть, но все же хотите обеспечить их возможностью коммуникаций по сети, можно поднять NAT ⁷. Для этого необходимо создать виртуальный коммутатор внутреннего типа командой (на данный момент настройка NAT возможна только через Powershell):

Создаем NAT:

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

Назначаем адрес для интерфейса:

На этом шаге внутреннему интерфейсу нужно присвоить адрес, который будет использоваться вложенными виртуальными машинами как шлюз. Конструкция команд, используемая на скриншоте выше, совсем необязательна, вы можете обойтись и без Get-NetAdapter ⁸, указав командлету New-NetIPAddress ⁹ индекс сетевого интерфейса (поле ifIndex). В этом случае моя команда выглядела бы таким образом: New-NetIPAddress -IPAddress 172.16.0.1 -AddressFamily IPv4 -PrefixLength 24 -InterfaceIndex 9.

Ну а теперь дело за малым: сконфигурируем сеть на вложенной виртуальной машине:

И проверим связь с внешним миром:

Переходим к последнему этапу.

Отключение динамической памяти

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

Или через Powershell командой:

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

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

comments powered by HyperComments