Вложенная виртуализация (nested virtualization) - это запуск гипервизора внутри виртуальной машины, а не на физическом сервере. Звучит как техническая экзотика, но на практике администраторы включают ее регулярно: чтобы поднять тестовый кластер Hyper-V, проверить обновление Proxmox VE перед выкаткой на боевые ноды или обучить новых инженеров работе с KVM без выделения отдельного железа.
Проблема в том, что многие путают лабораторный инструмент с production-архитектурой. Ниже разбираем, как устроена вложенная виртуализация технически, какие требования предъявляют производители и где проходит граница между «можно тестировать» и «нельзя строить SLA».
Архитектура: L0, L1, L2
Схема простая, но именно в терминологии чаще всего путаются на собеседованиях и в тикетах поддержки.
- L0 - физический сервер с базовым гипервизором (Hyper-V, ESXi, Proxmox VE, KVM), который управляет реальным железом.
- L1 - гостевая виртуальная машина, внутри которой запущен второй гипервизор.
- L2 - виртуальные машины, работающие уже внутри L1, то есть вложенные гости.
Для того чтобы L1 вообще увидел аппаратную виртуализацию, физический процессор должен поддерживать Intel VT-x или AMD-V, а гипервизор L0 обязан пробросить эти расширения внутрь гостя. Отдельно нужен второй уровень трансляции памяти: Intel EPT или AMD NPT/RVI. Без него гостевой гипервизор технически запустится, но производительность просядет так, что смысла в тесте почти не останется.
| Термин | Что это |
|---|---|
| L0 | Физический хост с bare-metal гипервизором |
| L1 | Гостевой гипервизор внутри ВМ на L0 |
| L2 | Вложенная виртуальная машина внутри L1 |
| VT-x | Аппаратные расширения виртуализации Intel |
| AMD-V / SVM | Аппаратные расширения виртуализации AMD |
| EPT | Extended Page Tables, второй уровень трансляции памяти у Intel |
| NPT / RVI | Аналог EPT у AMD |
Когда включать nested virtualization
Смысл в этой технологии появляется в нескольких конкретных ситуациях, и почти всегда речь о лаборатории, а не о боевой нагрузке.
Практика показывает, что чаще всего вложенную виртуализацию используют для:
- обучения администраторов работе с Hyper-V, ESXi, Proxmox VE или KVM без закупки отдельных серверов;
- проверки логики отказоустойчивого кластера, сценариев failover и процедур обновления гипервизора;
- PoC перед покупкой оборудования, когда архитектуру нужно смоделировать быстро и без физических нод;
- CI/CD и автоматизированного тестирования инфраструктурного ПО, где стенды создаются и удаляются десятками раз в день;
- изолированных контейнерных сценариев вроде Hyper-V isolated containers или WSL2.
Важно сразу разделить, что на nested-стенде проверять действительно можно, а что переносить на production нельзя ни при каких условиях.
| Можно проверить | Нельзя экстраполировать на production |
|---|---|
| Установку и обновление гипервизора | Latency СХД и реальные IOPS |
| Логику кластера и сценарии failover | SLA по доступности и восстановлению |
| Скрипты автоматизации, Ansible, Terraform | Производительность СУБД или 1С под нагрузкой |
| Обучение и сертификацию администраторов | Пропускную способность сети 25/100 Гбит/с |
| Тестирование backup/restore-процедур | Финальный sizing по vCPU, RAM и storage |
Это не универсальное правило, а именно тот подход, который на практике снимает большинство вопросов заказчика еще до старта проекта.
Аппаратные требования и совместимость
Минимум, без которого вложенная виртуализация просто не заработает: x86-64 процессор с VT-x или AMD-V и вторым уровнем трансляции адресов (EPT или NPT/RVI). Microsoft в документации по nested Hyper-V прямо указывает эти требования, а Intel и AMD описывают соответствующие механизмы в своей архитектурной документации.
| Платформа L0 | Минимум Intel | Минимум AMD | Ограничения |
|---|---|---|---|
| Hyper-V | Windows Server 2016 / Windows 10, VT-x + EPT | Windows Server 2022 / Windows 11, AMD-V + NPT | Dynamic Memory отключается, checkpoints ограничены |
| Proxmox VE | 7.x+, рекомендуется 8.x, VT-x + EPT | 7.x+, рекомендуется 8.x, AMD-V + NPT | CPU type host обязателен |
| KVM/libvirt | Ядро Linux 4.20+, VT-x | Ядро Linux 4.20+, AMD-V | host-passthrough обязателен |
| VMware ESXi | ESXi 6.7+, VT-x + EPT | ESXi 6.7+, AMD-V + RVI | Не поддерживается для production |
Здесь стоит сделать одну оговорку: ранние материалы про nested Hyper-V на AMD (примерно 2015 года) ограничивали технологию только процессорами Intel. Это давно устарело, современная документация Microsoft фиксирует поддержку AMD начиная с Windows Server 2022 и Windows 11. Если в интернете попадается старая статья с обратным утверждением, доверять ей не стоит.
Частая ошибка на этом этапе, причем не только у новичков: включают nested-режим только на уровне гипервизора, забыв проверить BIOS или UEFI физического сервера. Если VT-x или SVM отключены на железе, никакая команда внутри ВМ не даст результата, гостевой гипервизор просто не увидит нужные CPU-флаги.
По опыту работы с серверными платформами вроде HPE ProLiant DL380 Gen11 на двух Intel Xeon Gold 6430 (2 × 32 ядра, 256 ГБ RAM), такой конфигурации хватает на PoC-кластер из трех nested-гипервизоров с 4-6 вложенными гостями на каждом, если не гнаться за максимальной плотностью.
Sizing для лабораторных стендов
Цифры ниже - ориентир для планирования, а не бенчмарк. Реальная потребность зависит от гостевых ОС и характера нагрузки внутри L2.
| Профиль | vCPU на L1 | RAM на L1 | Storage | Сценарий |
|---|---|---|---|---|
| Минимальная лаборатория | 2-4 | 8-16 ГБ | 100-200 ГБ SSD | 1-2 nested ВМ, обучение |
| Стенд для обучения | 4-8 | 16-32 ГБ | 200-500 ГБ SSD/NVMe | 2-4 nested ВМ, имитация кластера |
| PoC кластера виртуализации | 8+ | 32-64 ГБ | 500+ ГБ NVMe | 3+ nested гипервизора, тестирование failover |
Как включить nested virtualization по платформам
Hyper-V
Включение выполняется на выключенной ВМ через PowerShell:
Stop-VM -Name "NestedHost01" Set-VMMemory -VMName "NestedHost01" -DynamicMemoryEnabled $false Set-VMProcessor -VMName "NestedHost01" -ExposeVirtualizationExtensions $true Start-VM -Name "NestedHost01"Проверить, применился ли параметр, можно так:
Get-VMProcessor -VMName "NestedHost01" | Select-Object ExposeVirtualizationExtensionsЕсли ВМ не загружается после включения, в девяти случаях из десяти причина в том, что забыли отключить Dynamic Memory, это одна из самых частых ошибок при первой настройке. Для сети вложенных гостей нужен MAC Address Spoofing на адаптере L1:
Set-VMNetworkAdapter -VMName "NestedHost01" -MacAddressSpoofing OnProxmox VE
Здесь включение происходит на двух уровнях: модуль ядра KVM и CPU type самой ВМ.
echo "options kvm_intel nested=1" > /etc/modprobe.d/kvm_intel.conf modprobe -r kvm_intel modprobe kvm_intel cat /sys/module/kvm_intel/parameters/nestedДля AMD команды аналогичны, только вместо kvm_intel везде kvm_amd. Для конкретной ВМ CPU type меняется через GUI (вкладка CPU) или командой:
qm set <VMID> --cpu hostМодуль ядра нельзя выгрузить, если на хосте работают ВМ, поэтому команды modprobe -r стоит выполнять только в maintenance window, иначе есть риск затронуть активные нагрузки.
KVM/libvirt
Логика та же, что в Proxmox, поскольку Proxmox использует KVM/QEMU под капотом. Дополнительно в libvirt для ВМ L1 нужен host-passthrough, а не именованная модель CPU:
<cpu mode='host-passthrough' check='none'/>Named CPU model не пробросит нужные флаги, и внутри гостя команда grep -E 'vmx|svm' /proc/cpuinfo не выдаст ничего, даже если на хосте nested-режим включен корректно.
VMware ESXi
Включается через опцию «Expose hardware assisted virtualization to the guest OS» в настройках CPU виртуальной машины (ВМ должна быть выключена). Автоматизировать это можно через PowerCLI:
$vm = Get-VM -Name "NestedESXi01" $spec = New-Object VMware.Vim.VirtualMachineConfigSpec $spec.NestedHVEnabled = $true $vm.ExtensionData.ReconfigVM_Task($spec)Для сети нужно перевести на порт-группе в Accept параметры Promiscuous mode, MAC address changes и Forged transmits, иначе трафик от вложенных гостей будет отбрасываться коммутатором как нелегитимный. Делать это стоит только на изолированной lab-portgroup: для production-сетей такая настройка заметно расширяет поверхность атаки.
Сеть: почему L2-гости часто «не пингуются»
Проблема одна и та же на всех платформах: MAC-адрес вложенной ВМ отличается от MAC самой ВМ L1, и коммутатор L0 по умолчанию отбрасывает такие кадры как подозрительные.
| Платформа | Решение |
|---|---|
| Hyper-V | MAC Address Spoofing или NAT |
| Proxmox VE / KVM | Linux bridge с нужными настройками MAC, либо NAT |
| VMware ESXi | Promiscuous mode, MAC changes, Forged transmits на port group |
Для корпоративной лаборатории на выделенном VLAN обычно проще и прозрачнее включить MAC spoofing или promiscuous mode. Для облачных стендов, где провайдер ограничивает L2-трафик по политике, остается только NAT, даже если он усложняет диагностику маршрутизации.
Ограничения и влияние на производительность
Каждый уровень вложения добавляет накладные расходы CPU, памяти и I/O. Больше всего страдает именно ввод-вывод: запрос проходит несколько уровней виртуальных устройств, и random I/O на nested-стенде может показывать latency в разы выше, чем на том же железе без вложения.
Microsoft прямо предупреждает, что nested Hyper-V не годится для производительно чувствительных приложений и не поддерживает Dynamic Memory, production checkpoints и часть сценариев live migration. Broadcom дает аналогичное предупреждение для nested ESXi: технология не рассчитана на production, за редкими специально оговоренными исключениями.
Открытых универсальных цифр деградации для Hyper-V, Proxmox/KVM и ESXi производители не публикуют, оценивать нужно конкретный профиль нагрузки инструментами вроде fio для storage, iperf3 для сети и stress-ng для CPU. Общая закономерность, которую подтверждает и практика, и материалы сообщества: потери на CPU обычно менее заметны, чем деградация storage I/O.
Диагностика частых проблем
| Симптом | Вероятная причина | Что сделать |
|---|---|---|
| Внутри L1 не видны vmx или svm | CPU-флаги не проброшены | Включить CPU type host / host-passthrough / Expose virtualization extensions |
| Hyper-V не устанавливается внутри ВМ | Dynamic Memory включена | Set-VMMemory -DynamicMemoryEnabled $false |
| Нет сети у L2-гостей в Hyper-V | Не включен MAC spoofing | Set-VMNetworkAdapter -MacAddressSpoofing On |
| L2-гости в ESXi не пингуются | Заблокированы MAC-адреса на порт-группе | Включить Promiscuous mode, MAC changes, Forged transmits |
| nested=1 включен, но KVM в L1 не стартует | ВМ использует generic CPU model | Установить host-passthrough |
| Низкая производительность storage | Двойной слой виртуального I/O | Не использовать nested для замеров latency СХД |
Безопасность и соответствие требованиям
Если на nested-стенде планируется работать с персональными данными, требования 152-ФЗ никуда не исчезают: production-данные в лаборатории без обезличивания использовать нельзя. Для организаций, подпадающих под 187-ФЗ о безопасности критической информационной инфраструктуры, лабораторные среды с вложенной виртуализацией должны быть изолированы от production-контуров. Отдельно стоит проверять совместимость сертифицированных средств защиты информации с nested-архитектурой по требованиям ФСТЭК, до развертывания, а не после.
Практический итог
По данным за 2026 год вложенная виртуализация остается в первую очередь инженерным инструментом для обучения, PoC и тестирования, а не архитектурой для промышленной эксплуатации. Прежде чем разворачивать стенд, стоит пройти короткий чек-лист:
- Проверить поддержку VT-x/AMD-V с EPT/NPT на процессоре и убедиться, что виртуализация включена в BIOS или UEFI.
- Определить масштаб: сколько L2-гостей нужно и требуется ли отказоустойчивость на уровне L1.
- Заложить ресурсы с запасом, используя таблицу sizing выше как ориентир, а не жесткий норматив.
- Изолировать lab-сеть и не включать promiscuous mode или MAC spoofing на production-портах.
- Не переносить результаты по latency, IOPS и throughput с nested-стенда напрямую в расчеты боевой инфраструктуры.
Если задача - протестировать логику кластера, обновление гипервизора или обучить команду, nested virtualization экономит физические серверы и время. Если речь о боевой нагрузке с требованиями к SLA, разумнее сразу проектировать под гипервизор первого уровня на bare metal.
