Tilda Publishing
Привет, любопытный друг. Да, это Tilda. Потому что мы хотим быстро внедрять и управлять решением, а не ждать
в очереди разработчика. Контроль, предсказуемость и отказоустойчивость — наша главная идея.
в очереди разработчика. Контроль, предсказуемость и отказоустойчивость — наша главная идея.
Заказать обратный звонок
Оставьте номер телефона — мы свяжемся с вами в ближайшее время, ответим на вопросы и подберём оптимальное решение.
Для запросов и ТЗ
с 9:30 до 18:00
Подберём типовое или произведем на заказ серверное оборудование, предоставим расчёт и поможем интегрировать в систему.
Заполните форму запроса слева или отправьте описание вашей задачи на почту get@work-system.ru
При отправке письма на почту укажите номер телефона вашего специалиста для обсуждения аналогов оборудования в случае необходимости
Заполните форму запроса слева или отправьте описание вашей задачи на почту get@work-system.ru
При отправке письма на почту укажите номер телефона вашего специалиста для обсуждения аналогов оборудования в случае необходимости
Вложенная виртуализация (Nested Virtualization): как включить и настроить
Вложенная виртуализация, или nested virtualization — это ситуация, когда гипервизор запускается не на физическом сервере, а внутри виртуальной машины. На практике это позволяет поднять Hyper-V, KVM, Proxmox VE или VMware ESXi как гостевой гипервизор и уже внутри него запустить вложенные виртуальные машины.
Мы в Work System рассматриваем такую архитектуру как инструмент для лабораторий, тестирования, обучения и PoC — но не как типовой вариант для высоконагруженного production. По данным документации «Run Hyper-V in a Virtual Machine with Nested Virtualization» от Microsoft, 2025, nested Hyper-V не подходит для чувствительных к производительности приложений. Причина техническая: появляется дополнительный уровень трансляции CPU, памяти, сети и I/O. Технология требует аппаратной виртуализации и имеет ограничения по динамической памяти, checkpoints и live migration. Аналогичные предупреждения для nested ESXi приводит Broadcom в KB «Support for running ESXi as a nested virtualization solution», 2024. Если вы только разворачиваете базовую платформу, начните с выбора сервера виртуализации, а затем решайте, нужен ли дополнительный уровень вложения.
Мы в Work System рассматриваем такую архитектуру как инструмент для лабораторий, тестирования, обучения и PoC — но не как типовой вариант для высоконагруженного production. По данным документации «Run Hyper-V in a Virtual Machine with Nested Virtualization» от Microsoft, 2025, nested Hyper-V не подходит для чувствительных к производительности приложений. Причина техническая: появляется дополнительный уровень трансляции CPU, памяти, сети и I/O. Технология требует аппаратной виртуализации и имеет ограничения по динамической памяти, checkpoints и live migration. Аналогичные предупреждения для nested ESXi приводит Broadcom в KB «Support for running ESXi as a nested virtualization solution», 2024. Если вы только разворачиваете базовую платформу, начните с выбора сервера виртуализации, а затем решайте, нужен ли дополнительный уровень вложения.
Содержание
12
Коротко: что включить на каждой платформе
Nested virtualization всегда требует двух вещей: пробросить CPU virtualization extensions в L1-гипервизор и настроить сеть так, чтобы L2-гости могли передавать трафик через L1. Вот краткая сводка по платформам.
Платформа L0
Что включить для L1
Минимальная проверка
Сеть для L2
Hyper-V
Set-VMProcessor -ExposeVirtualizationExtensions $true
ВМ L1 выключена, Dynamic Memory отключена
MAC Address Spoofing или NAT
Proxmox VE
Nested mode в kvm_intel/kvm_amd и CPU type host
cat /sys/module/kvm_*/parameters/nested, grep -E 'vmx|svm' /proc/cpuinfo
Linux bridge, VLAN, при необходимости настройки MAC
KVM/libvirt
nested=1 и host-passthrough
/sys/module/.../nested, CPU flags внутри L1
bridge/NAT по схеме стенда
VMware ESXi
«Expose hardware assisted virtualization to the guest OS»
Гостевая ОС видит VT-x/AMD-V
Promiscuous mode, MAC address changes, Forged transmits или MAC learning
Что такое вложенная виртуализация и зачем она нужна
Вложенная виртуализация — это запуск гипервизора L1 внутри виртуальной машины, которая уже работает на гипервизоре L0. После этого внутри L1 можно создать ВМ уровня L2 — по сути, получить виртуализацию внутри виртуальной машины.
Архитектура выглядит так: физический сервер и его CPU находятся на уровне L0, базовый гипервизор управляет железом, гостевая ВМ получает проброшенные расширения VT-x или AMD-V — подробнее об этих технологиях читайте в статье про аппаратную виртуализацию процессора — а установленный внутри неё гипервизор создаёт вложенные виртуальные машины. По данным «Running nested guests with KVM» от Linux Kernel Documentation, 2024, L0 — bare-metal хост, L1 — гостевой гипервизор, L2 — вложенный гость.
Архитектура выглядит так: физический сервер и его CPU находятся на уровне L0, базовый гипервизор управляет железом, гостевая ВМ получает проброшенные расширения VT-x или AMD-V — подробнее об этих технологиях читайте в статье про аппаратную виртуализацию процессора — а установленный внутри неё гипервизор создаёт вложенные виртуальные машины. По данным «Running nested guests with KVM» от Linux Kernel Documentation, 2024, L0 — bare-metal хост, L1 — гостевой гипервизор, L2 — вложенный гость.
Мини-глоссарий
Термин
Описание
L0
Физический хост с bare-metal гипервизором
L1
Гостевой гипервизор, запущенный внутри ВМ на L0
L2
Вложенная виртуальная машина, запущенная внутри L1
VT-x
Intel Virtualization Technology — аппаратные расширения виртуализации Intel
AMD-V / SVM
AMD Virtualization — аппаратные расширения виртуализации AMD
EPT
Extended Page Tables — второй уровень трансляции адресов памяти Intel
NPT / RVI
Nested Page Tables / Rapid Virtualization Indexing — аналог EPT от AMD
VM-exit / VM-entry
Переключения контекста между гостем и гипервизором
Теперь — к сценариям. Когда вообще имеет смысл включить вложенную виртуализацию?
Сценарий
Когда применять
Что важно проверить
Лаборатория Hyper-V, VMware ESXi, KVM или Proxmox
Обучение администраторов, проверка настроек кластера, тестирование обновлений
Поддержка VT-x/AMD-V, EPT/NPT, достаточный объём RAM
PoC перед закупкой оборудования
Нужно смоделировать архитектуру без выделения нескольких физических серверов
Ограничения по производительности и сетевой связности
CI/CD и тестирование инфраструктурного ПО
Требуется быстро создавать и удалять стенды с гипервизорами
Автоматизация включения CPU-флагов и сетевых режимов
Контейнеризация с изоляцией
Нужны Hyper-V isolated containers, WSL2, VBS-сценарии
Совместимость гостевой ОС и гипервизора L0
Тестирование отказоустойчивости
Нужно смоделировать кластер, ноды, сети и хранилища
Нельзя переносить выводы по latency напрямую в production
При проектировании инфраструктуры виртуализации и резервного копирования для ППК «Косино» наша команда чётко отделяла лабораторные проверки от расчётов production-среды. Nested virtualization удобна для проверки логики кластера и процедур обновления, но расчёт production-нагрузки всё равно делается на физической или штатной виртуальной платформе — без лишнего уровня вложения.
Что можно и что нельзя проверять на nested-стенде
Это, пожалуй, самый частый вопрос, который задают наши инженеры заказчикам перед развёртыванием лаборатории.
Можно проверить
Нельзя экстраполировать на production
Установка и обновление гипервизора
Latency СХД и IOPS
Логика кластера, сценарии failover
SLA по доступности и восстановлению
Скрипты автоматизации, Ansible/Terraform
Реальная производительность СУБД или 1С
Обучение администраторов и сертификация
Пропускная способность 25/100 Гбит/с
Тестирование backup/restore-процедур
Финальный sizing vCPU/RAM/storage
Практический вывод: включить вложенную виртуализацию имеет смысл, если вам нужно запустить виртуальные машины внутри виртуальной машины для теста, обучения или PoC. Для постоянной нагрузки с требованием к SLA лучше использовать гипервизор первого уровня на bare metal.
Аппаратные требования к процессорам
Для вложенной виртуализации нужен x86-64 CPU с аппаратной виртуализацией и вторым уровнем трансляции адресов памяти: Intel VT-x с EPT или AMD-V с NPT/RVI. По данным документации «Run Hyper-V in a Virtual Machine with Nested Virtualization» от Microsoft, 2025, для nested Hyper-V требуются именно Intel EPT или AMD NPT/RVI. Без этих функций виртуальной машины будет недостаточно для стабильной работы гостевого гипервизора.
По данным «Intel VT for Intel 64 and IA-32 Architectures» от Intel, 2024, VT-x включает EPT, VPID и guest preemption timer. Intel описывает VMX, VMCS, VM-entry и VM-exit в соответствующих разделах документации. Extended Page Tables указаны как механизм трансляции гостевых физических адресов в хостовые. AMD описывает SVM, VMRUN, VMLOAD, VMSAVE и nested paging в «AMD64 Architecture Programmer's Manual, Volume 2: System Programming, Revision 3.40». Аппаратные расширения CPU дают базовые инструкции виртуализации, а nested-режим включается и ограничивается конкретным гипервизором L0.
По данным «Intel VT for Intel 64 and IA-32 Architectures» от Intel, 2024, VT-x включает EPT, VPID и guest preemption timer. Intel описывает VMX, VMCS, VM-entry и VM-exit в соответствующих разделах документации. Extended Page Tables указаны как механизм трансляции гостевых физических адресов в хостовые. AMD описывает SVM, VMRUN, VMLOAD, VMSAVE и nested paging в «AMD64 Architecture Programmer's Manual, Volume 2: System Programming, Revision 3.40». Аппаратные расширения CPU дают базовые инструкции виртуализации, а nested-режим включается и ограничивается конкретным гипервизором L0.
Матрица совместимости по платформам и версиям
Платформа L0
Минимальная версия (Intel)
Минимальная версия (AMD)
CPU-требование
Ограничения
Hyper-V
Windows Server 2016 / Windows 10
Windows Server 2022 / Windows 11
VT-x + EPT / AMD-V + NPT
Dynamic Memory off, checkpoints ограничены
Proxmox VE
7.x+ (ядро 5.x+), рекомендуется 8.x
7.x+ (ядро 5.x+), рекомендуется 8.x
VT-x + EPT / AMD-V + NPT
CPU type host обязателен
KVM/libvirt
Ядро Linux 4.20+ (nested часто по умолчанию)
Ядро Linux 4.20+
VT-x / AMD-V
host-passthrough обязателен
VMware ESXi
ESXi 6.7+
ESXi 6.7+
VT-x + EPT / AMD-V + RVI
Nested ESXi не поддерживается в production
Минимальный технический набор:
Компонент
Требование
Комментарий
CPU Intel
VT-x, VMX, EPT
Для Hyper-V и ESXi EPT критичен для приемлемой работы
CPU AMD
AMD-V, SVM, NPT/RVI
Для Hyper-V на AMD Microsoft указывает Windows Server 2022/Windows 11 и новее. Ранние материалы 2015 года ограничивали nested Hyper-V только Intel — это устарело
BIOS/UEFI
Включённая аппаратная виртуализация
На серверах параметр может называться Intel Virtualization Technology, SVM Mode, AMD-V
Гипервизор L0
Поддержка nested virtualization
Hyper-V, KVM/Proxmox и ESXi включают её по-разному
RAM
Запас под L0, L1 и L2
Память расходуется на несколько уровней ОС и гипервизоров
Storage
Низкая latency для лабораторий с несколькими ВМ
I/O страдает сильнее CPU при двойной виртуализации
Типичная ошибка — пытаться включить nested virtualization только настройкой в гипервизоре, не проверив BIOS/UEFI. Если VT-x или SVM отключены на физическом сервере, команда на уровне ВМ не даст результата: гостевой гипервизор просто не увидит нужные CPU-флаги. Подробную инструкцию по проверке BIOS/UEFI смотрите в статье про включение виртуализации в BIOS
Практический вывод: перед настройкой проверьте не только модель процессора, но и включение virtualization extensions в BIOS/UEFI, версию гипервизора L0 и CPU type гостевой ВМ. Для серверных стендов мы обычно закладываем запас по ядрам и памяти — L1-гипервизор сам потребляет ресурсы ещё до запуска вложенных гостей. Скажем, на HPE ProLiant DL380 Gen11 с двумя Intel Xeon Gold 6430 (2 × 32 ядра) и 256 ГБ RAM можно комфортно развернуть PoC-кластер из трёх nested-гипервизоров с 4–6 L2-гостями на каждом.
Практический вывод: перед настройкой проверьте не только модель процессора, но и включение virtualization extensions в BIOS/UEFI, версию гипервизора L0 и CPU type гостевой ВМ. Для серверных стендов мы обычно закладываем запас по ядрам и памяти — L1-гипервизор сам потребляет ресурсы ещё до запуска вложенных гостей. Скажем, на HPE ProLiant DL380 Gen11 с двумя Intel Xeon Gold 6430 (2 × 32 ядра) и 256 ГБ RAM можно комфортно развернуть PoC-кластер из трёх nested-гипервизоров с 4–6 L2-гостями на каждом.
Ориентировочный 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
Как включить вложенную виртуализацию в Hyper-V
Чтобы включить вложенную виртуализацию Hyper-V, нужно остановить ВМ L1 и разрешить ей видеть аппаратные расширения виртуализации через PowerShell. После этого внутри гостевой Windows можно установить роль гипервизора Hyper-V и запустить вложенные виртуальные машины.
По данным «Run Hyper-V in a Virtual Machine with Nested Virtualization» от Microsoft, 2025, параметр ExposeVirtualizationExtensions включается на выключенной ВМ. Документ также фиксирует ограничения: Dynamic Memory не поддерживается, production checkpoints не поддерживаются, live migration и некоторые failover-сценарии ограничены. Поэтому включить nested virtualization Hyper-V для лаборатории — нормальная практика. А вот для production-кластера Windows Server Failover Clustering — уже рискованная архитектура.
Перед настройкой проверьте:
Пример подготовки ВМ:
По данным «Run Hyper-V in a Virtual Machine with Nested Virtualization» от Microsoft, 2025, параметр ExposeVirtualizationExtensions включается на выключенной ВМ. Документ также фиксирует ограничения: Dynamic Memory не поддерживается, production checkpoints не поддерживаются, live migration и некоторые failover-сценарии ограничены. Поэтому включить nested virtualization Hyper-V для лаборатории — нормальная практика. А вот для production-кластера Windows Server Failover Clustering — уже рискованная архитектура.
Перед настройкой проверьте:
- Хост Hyper-V работает на Windows Server 2016/Windows 10 или новее для Intel.
- Для AMD используется Windows Server 2022/Windows 11 или новее.
- Процессор поддерживает VT-x/EPT или AMD-V/RVI.
- Гостевая ВМ выключена.
- Dynamic Memory отключена. Если забыть этот шаг, ВМ может не загрузиться — и это одна из самых частых ошибок при первой настройке.
- Для сетевой связности выбран MAC Address Spoofing или NAT.
Пример подготовки ВМ:
Stop-VM -Name "NestedHost01"
Set-VMMemory -VMName "NestedHost01" -DynamicMemoryEnabled $false
Set-VMProcessor -VMName "NestedHost01" -ExposeVirtualizationExtensions $true
Start-VM -Name "NestedHost01"После запуска гостевой Windows установите роль Hyper-V уже внутри этой виртуальной машины. С этого момента ВМ L1 будет вести себя как отдельный Hyper-V-хост, но её ресурсы ограничены тем, что выделено на L0.
Проверка состояния параметра
После включения убедитесь, что параметр применён:
Get-VMProcessor -VMName "NestedHost01" | Select-Object ExposeVirtualizationExtensionsЕсли значение True — nested virtualization для этой ВМ активна. Можно двигаться дальше.
Практический вывод: если задача — включить вложенную виртуализацию Hyper-V для учебного стенда или проверки скриптов, используйте PowerShell и заранее отключите динамическую память. Если задача — перенести боевую нагрузку в nested Hyper-V, сначала проверьте ограничения Microsoft по checkpoints, live migration и производительности.
Практический вывод: если задача — включить вложенную виртуализацию Hyper-V для учебного стенда или проверки скриптов, используйте PowerShell и заранее отключите динамическую память. Если задача — перенести боевую нагрузку в nested Hyper-V, сначала проверьте ограничения Microsoft по checkpoints, live migration и производительности.
Включение поддержки через PowerShell
Поддержка nested virtualization в Hyper-V включается командлетом Set-VMProcessor на выключенной виртуальной машине. Именно этот параметр пробрасывает гостю virtualization extensions, а не установка роли Hyper-V внутри ОС — подробнее о самой установке в статье про включение Hyper-V.
Синтаксис:
Синтаксис:
Set-VMProcessor -VMName "VMName" -ExposeVirtualizationExtensions $trueДля отключения — обратное значение:
Set-VMProcessor -VMName "VMName" -ExposeVirtualizationExtensions $falseПроверочный сценарий целиком:
$VMName = "NestedHost01"
Stop-VM -Name $VMName
Set-VMMemory -VMName $VMName -DynamicMemoryEnabled $false
Set-VMProcessor -VMName $VMName -ExposeVirtualizationExtensions $true
Start-VM -Name $VMNameЕсли внутри гостевой Windows роль Hyper-V не устанавливается или сообщает об отсутствии аппаратной виртуализации, проверьте три уровня: BIOS/UEFI физического сервера, параметр ExposeVirtualizationExtensions, а также версию конфигурации ВМ. Бывает, что ВМ создана в старом формате конфигурации — и тогда параметр просто не применяется.
Альтернатива: скрипт Enable-NestedVm.ps1
Кроме ручной команды Set-VMProcessor, Microsoft в своих материалах ранее предлагала скриптовый подход через Enable-NestedVm.ps1. Он удобен тем, что автоматически проверяет часть требований: выключенное состояние ВМ, Dynamic Memory и другие параметры.
Используйте такой способ только после проверки актуального URL Microsoft-репозитория и содержимого скрипта:
Используйте такой способ только после проверки актуального URL Microsoft-репозитория и содержимого скрипта:
Invoke-WebRequest "<актуальный_URL_скрипта_Microsoft>" -OutFile .\Enable-NestedVm.ps1
.\Enable-NestedVm.ps1 -VmName "NestedHost01"Для production-подхода безопаснее явно понимать, какие параметры меняет скрипт: CPU extensions, Dynamic Memory, сетевые настройки и другие ограничения nested Hyper-V. Мы в своих проектах предпочитаем ручной набор команд — так проще отследить, что именно изменилось.
Практический вывод: для запроса «enable nested virtualization» в Hyper-V основная команда — Set-VMProcessor -VMName "<имя_ВМ>" -ExposeVirtualizationExtensions $true. Выполняйте её на L0-хосте, а не внутри гостевой ОС. Для автоматической проверки требований можно использовать скрипт Microsoft, но всегда верифицируйте его перед запуском.
Практический вывод: для запроса «enable nested virtualization» в Hyper-V основная команда — Set-VMProcessor -VMName "<имя_ВМ>" -ExposeVirtualizationExtensions $true. Выполняйте её на L0-хосте, а не внутри гостевой ОС. Для автоматической проверки требований можно использовать скрипт Microsoft, но всегда верифицируйте его перед запуском.
Настройка сети (MAC Address Spoofing)
Для сетевой связности вложенных ВМ в Hyper-V обычно нужно включить MAC Address Spoofing на сетевом адаптере ВМ L1. Без этого внешний vSwitch может отбрасывать кадры — они приходят с MAC-адресов вложенных виртуальных машин, а не с MAC самой ВМ L1.
По данным «Run Hyper-V in a Virtual Machine with Nested Virtualization» от Microsoft, 2025, для сети L2 используется MAC Address Spoofing или NAT. Базовый синтаксис:
По данным «Run Hyper-V in a Virtual Machine with Nested Virtualization» от Microsoft, 2025, для сети L2 используется MAC Address Spoofing или NAT. Базовый синтаксис:
Set-VMNetworkAdapter -VMName "VMName" -MacAddressSpoofing OnЕсли нужно применить настройку через pipeline:
Get-VMNetworkAdapter -VMName "NestedHost01" |
Set-VMNetworkAdapter -MacAddressSpoofing OnКоманда Set-VMNetworkAdapter -VMName "NestedHost01" -MacAddressSpoofing On разрешает ВМ L1 передавать трафик от вложенных гостей L2. Это особенно важно, если внутри L1 создан внешний виртуальный коммутатор Hyper-V, а вложенные ВМ должны получать доступ в корпоративную сеть.
Альтернатива — NAT внутри L1. Этот вариант полезен, когда политика безопасности запрещает MAC spoofing или когда L1 находится в облаке с ограничениями на L2-адресацию. Microsoft описывает подход с Internal vSwitch и NAT-объектом, но для корпоративного стенда такой вариант заметно усложняет диагностику маршрутизации.
Практический вывод: если вложенные виртуальные машины в Hyper-V не выходят в сеть, первым делом проверьте Set-VMNetworkAdapter -VMName "<имя_ВМ>" -MacAddressSpoofing On. Это самая частая причина, по которой nested virtualization «завелась», но сеть L2 не работает.
Альтернатива — NAT внутри L1. Этот вариант полезен, когда политика безопасности запрещает MAC spoofing или когда L1 находится в облаке с ограничениями на L2-адресацию. Microsoft описывает подход с Internal vSwitch и NAT-объектом, но для корпоративного стенда такой вариант заметно усложняет диагностику маршрутизации.
Практический вывод: если вложенные виртуальные машины в Hyper-V не выходят в сеть, первым делом проверьте Set-VMNetworkAdapter -VMName "<имя_ВМ>" -MacAddressSpoofing On. Это самая частая причина, по которой nested virtualization «завелась», но сеть L2 не работает.
Настройка Nested Virtualization в Proxmox VE
В Proxmox VE вложенная виртуализация включается на двух уровнях: модуль KVM на хосте и тип CPU конкретной ВМ. Платформа виртуализации Proxmox VE использует KVM/QEMU, поэтому для nested-режима достаточно включить nested mode в ядре и выбрать CPU type host для ВМ.
По данным «Running nested guests with KVM» от Linux Kernel Documentation, 2024, с Linux 4.20 nested включён по умолчанию, но дистрибутивы могут переопределять параметр. Поэтому проверку лучше выполнять явно. Для Intel:
По данным «Running nested guests with KVM» от Linux Kernel Documentation, 2024, с Linux 4.20 nested включён по умолчанию, но дистрибутивы могут переопределять параметр. Поэтому проверку лучше выполнять явно. Для Intel:
cat /sys/module/kvm_intel/parameters/nestedДля AMD:
cat /sys/module/kvm_amd/parameters/nestedЗначение Y или 1 означает, что nested virtualization включена. Значение N или 0 — режим выключен.
Для включения на Intel обычно задают параметр модуля:
Для включения на Intel обычно задают параметр модуля:
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:
echo "options kvm_amd nested=1" > /etc/modprobe.d/kvm_amd.conf
modprobe -r kvm_amd
modprobe kvm_amd
cat /sys/module/kvm_amd/parameters/nestedВажно: команды modprobe -r kvm_intel и modprobe -r kvm_amd выполняйте только в maintenance window. Если на хосте работают виртуальные машины, модуль может не выгрузиться — или операция затронет активные нагрузки. Для production-хоста безопаснее запланировать перезагрузку после изменения /etc/modprobe.d/*.conf.
Настройка через GUI и конфигурационный файл
Для конкретной ВМ в интерфейсе Proxmox VE откройте настройки → вкладка CPU → выберите CPU type host. Через CLI это делается командой:
qm set <VMID> --cpu hostВ конфигурационном файле это соответствует строке:
cpu: hostФайл ВМ расположен в каталоге:
/etc/pve/qemu-server/<VMID>.confПосле изменений можно проверить конфигурацию:
grep cpu /etc/pve/qemu-server/<VMID>.confПосле запуска гостевой Linux проверьте, видны ли флаги:
grep -E 'vmx|svm' /proc/cpuinfoЕсли внутри гостя должен работать Hyper-V, дополнительно учитывайте Hyper-V enlightenments в QEMU. По данным «Hyper-V Enlightenments» от QEMU Project, 2024, флаги hv_time, hv_vpindex и hv_relaxed оптимизируют Windows-гостей поверх KVM. Без них Windows внутри L1 может работать заметно медленнее — вплоть до зависаний при загрузке.
Откат настроек Proxmox
Для отключения nested virtualization в Proxmox верните CPU type на желаемый (например, kvm64) через GUI или командой:
qm set <VMID> --cpu kvm64Для отключения nested mode на уровне хоста удалите или измените файл в /etc/modprobe.d/ и перезагрузите хост.
Практический вывод: чтобы включить вложенную виртуализацию Proxmox, проверьте /sys/module/kvm_intel/parameters/nested или /sys/module/kvm_amd/parameters/nested, затем задайте CPU type host для нужной ВМ через GUI или qm set. Если гостевая ОС не видит vmx или svm, nested-гипервизор внутри неё не запустится.
Практический вывод: чтобы включить вложенную виртуализацию Proxmox, проверьте /sys/module/kvm_intel/parameters/nested или /sys/module/kvm_amd/parameters/nested, затем задайте CPU type host для нужной ВМ через GUI или qm set. Если гостевая ОС не видит vmx или svm, nested-гипервизор внутри неё не запустится.
Как включить Nested Virtualization в KVM
В нативном KVM nested virtualization включается параметрами модулей ядра kvm_intel или kvm_amd, а гостевой ВМ передаётся CPU-модель с флагами аппаратной виртуализации. Это базовый способ для KVM-виртуализации в Linux: Ubuntu, RHEL, Alma Linux, Rocky Linux и других дистрибутивов, где KVM работает как модуль ядра.
По данным «Running nested guests with KVM» от Linux Kernel Documentation, 2024, L1-гостю нужно передать CPU с флагом vmx или svm. Для Intel используется kvm_intel nested=1 или nested=Y, для AMD — kvm_amd nested=1.
Проверка текущего статуса:
По данным «Running nested guests with KVM» от Linux Kernel Documentation, 2024, L1-гостю нужно передать CPU с флагом vmx или svm. Для Intel используется kvm_intel nested=1 или nested=Y, для AMD — kvm_amd nested=1.
Проверка текущего статуса:
cat /sys/module/kvm_intel/parameters/nested
cat /sys/module/kvm_amd/parameters/nestedПостоянное включение для Intel:
echo "options kvm_intel nested=1" > /etc/modprobe.d/kvm_intel.conf
modprobe -r kvm_intel
modprobe kvm_intelПостоянное включение для AMD:
echo "options kvm_amd nested=1" > /etc/modprobe.d/kvm_amd.conf
modprobe -r kvm_amd
modprobe kvm_amdВажно: выгрузка модулей kvm_intel / kvm_amd невозможна или рискованна при работающих ВМ. Если modprobe -r завершается ошибкой, запланируйте перезагрузку хоста в maintenance window.
После этого при запуске ВМ L1 используйте CPU passthrough. Для QEMU/KVM это обычно выглядит так:
qemu-system-x86_64 -enable-kvm -cpu hostЕсли используется libvirt, проверьте CPU mode в XML-конфигурации. Для nested-лабораторий нужен host-passthrough, а не named CPU model:
<cpu mode='host-passthrough' check='none'/>Настройка через virsh edit <имя_ВМ> позволяет внести изменения в XML-конфигурацию. Учитывайте, что host-passthrough ухудшает переносимость ВМ между хостами с разными CPU — для мигрируемых кластеров это компромисс, который стоит осознавать заранее.
Внутри гостевой Linux:
Внутри гостевой Linux:
grep -E 'vmx|svm' /proc/cpuinfoЕсли команда ничего не выводит, L1-гость не видит аппаратную виртуализацию. В таком состоянии KVM nested virtualization включить не получится, даже если модуль на L0 настроен правильно.
Откат настроек KVM
Для отключения nested virtualization на уровне хоста:
Для ВМ смените CPU mode на нужную модель в libvirt XML.
В проектах с Linux/KVM типичная ошибка — включить nested=1 на хосте, но оставить гостевой ВМ универсальную CPU-модель без vmx или svm. Для мигрируемых кластеров это иногда делают намеренно ради совместимости между разными поколениями процессоров, но для nested-лаборатории такой компромисс ломает основную функцию. Вроде мелочь, а отнимает часы на диагностику.
Практический вывод: ответ на запрос «kvm nested virtualization включить» состоит из двух частей — включить nested в модуле ядра и передать CPU-флаги в ВМ L1. Одного параметра nested=1 недостаточно.
- Удалите или закомментируйте строку options kvm_intel nested=1 в /etc/modprobe.d/kvm_intel.conf.
- Перезагрузите хост или перезагрузите модуль в maintenance window.
Для ВМ смените CPU mode на нужную модель в libvirt XML.
В проектах с Linux/KVM типичная ошибка — включить nested=1 на хосте, но оставить гостевой ВМ универсальную CPU-модель без vmx или svm. Для мигрируемых кластеров это иногда делают намеренно ради совместимости между разными поколениями процессоров, но для nested-лаборатории такой компромисс ломает основную функцию. Вроде мелочь, а отнимает часы на диагностику.
Практический вывод: ответ на запрос «kvm nested virtualization включить» состоит из двух частей — включить nested в модуле ядра и передать CPU-флаги в ВМ L1. Одного параметра nested=1 недостаточно.
Вложенная виртуализация в VMware ESXi
В VMware ESXi nested virtualization включается для конкретной ВМ через опцию «Expose hardware assisted virtualization to the guest OS». После этого гостевая ОС получает доступ к VT-x или AMD-V и может запустить вложенные виртуальные машины через ESXi, Hyper-V, KVM или другой гипервизор.
По данным «Support for running ESXi as a nested virtualization solution» от Broadcom, 2024, nested ESXi не поддерживается как production-архитектура. Технология широко применяется для лабораторий, обучения и PoC, но не для SLA-нагрузок, за исключением отдельных специально оговорённых сценариев. В материалах VMware Cloud Foundation nested ESXi рассматривается как инструмент test/PoC/lab-сред.
Базовая настройка:
По данным «Support for running ESXi as a nested virtualization solution» от Broadcom, 2024, nested ESXi не поддерживается как production-архитектура. Технология широко применяется для лабораторий, обучения и PoC, но не для SLA-нагрузок, за исключением отдельных специально оговорённых сценариев. В материалах VMware Cloud Foundation nested ESXi рассматривается как инструмент test/PoC/lab-сред.
Базовая настройка:
- Остановите ВМ, которая будет L1-гипервизором.
- Откройте настройки ВМ в vSphere Client.
- Перейдите в раздел CPU.
- Включите «Expose hardware assisted virtualization to the guest OS».
- Запустите ВМ и установите гостевой гипервизор.
- Проверьте, видит ли гостевая ОС VT-x/AMD-V (внутри Linux — grep -E 'vmx|svm' /proc/cpuinfo, внутри Windows — диспетчер задач → вкладка «Производительность» → раздел CPU → «Виртуализация»).
Автоматизация через PowerCLI
По данным «Nested Virtualization in VMware ESXi and Hyper-V» от StarWind, 2024, nestedHVEnabled можно включать через VirtualMachineConfigSpec. Пример PowerCLI:
$vm = Get-VM -Name "NestedESXi01"
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.NestedHVEnabled = $true
$vm.ExtensionData.ReconfigVM_Task($spec)Проверьте синтаксис в актуальной версии PowerCLI перед применением — между версиями бывают нюансы.
Настройка сети для nested ESXi
Сеть в VMware ESXi требует отдельного внимания. По VMware vSphere Security Configuration Guide, 2024–2025, для порт-группы доступны параметры Promiscuous mode, MAC address changes и Forged transmits. Для nested ESXi их часто переводят в Accept, чтобы вложенные виртуальные машины могли отправлять и принимать кадры со своими MAC-адресами.
Предупреждение по безопасности: включайте Promiscuous mode, MAC address changes и Forged transmits только на lab-portgroup. Для production-сетей эти настройки расширяют поверхность атаки.
Минимальный набор для nested-сети ESXi:
Настройка порт-группы
Режим для nested-сценария
Зачем нужна
Promiscuous mode
Accept
L1-гипервизор видит трафик не только на свой MAC
MAC address changes
Accept
Разрешается смена MAC на виртуальном NIC
Forged transmits
Accept
Разрешаются исходящие кадры с MAC вложенных ВМ
MAC learning
Если доступно в версии vSphere
Более аккуратная альтернатива promiscuous mode
Причина проста: для L0-свитча все пакеты от L2-гостей приходят через порт ВМ L1. Если политика безопасности запрещает «чужие» MAC-адреса, трафик вложенных ВМ будет отфильтрован. По данным «Why is Promiscuous Mode & Forged Transmits required for Nested ESXi» от VMware, 2024, L0-свитч отбрасывает неизвестные MAC вложенных ВМ.
В проектах Work System по кластерам виртуализации мы используем nested-подход только для предварительной проверки логики и обучения администраторов. Например, при построении инфраструктуры виртуализации и резервного копирования для ППК «Косино» ключевыми production-требованиями были снапшоты, репликация, дедупликация, кластеризация и LUN. Такие функции проверяются в лаборатории, но финальные расчёты отказоустойчивости и производительности выполняются на целевой платформе — скажем, на Dell PowerEdge R750xa с локальными NVMe-дисками или на связке с внешней СХД.
Практический вывод: чтобы запустить вложенные виртуальные машины на VMware ESXi, включите «Expose hardware assisted virtualization to the guest OS» и настройте порт-группу. Если CPU-флаги видны, но сеть L2 не работает — проверьте Promiscuous mode, Forged transmits и MAC address changes.
В проектах Work System по кластерам виртуализации мы используем nested-подход только для предварительной проверки логики и обучения администраторов. Например, при построении инфраструктуры виртуализации и резервного копирования для ППК «Косино» ключевыми production-требованиями были снапшоты, репликация, дедупликация, кластеризация и LUN. Такие функции проверяются в лаборатории, но финальные расчёты отказоустойчивости и производительности выполняются на целевой платформе — скажем, на Dell PowerEdge R750xa с локальными NVMe-дисками или на связке с внешней СХД.
Практический вывод: чтобы запустить вложенные виртуальные машины на VMware ESXi, включите «Expose hardware assisted virtualization to the guest OS» и настройте порт-группу. Если CPU-флаги видны, но сеть L2 не работает — проверьте Promiscuous mode, Forged transmits и MAC address changes.
Сеть во вложенной виртуализации: общие принципы
Сетевые проблемы — одна из самых частых причин, по которой nested virtualization «работает», но L2-гости не получают сеть. Корневая причина одинакова на всех платформах: L2-виртуальная машина использует MAC-адрес, который отличается от MAC ВМ L1. Для L0-свитча такой кадр выглядит как нелегитимный, и по умолчанию он отбрасывается.
Платформа
Способ решения
Команда / настройка
Hyper-V
MAC Address Spoofing или NAT
Set-VMNetworkAdapter -MacAddressSpoofing On
Proxmox VE / KVM
Linux bridge + настройки MAC, либо NAT
Bridge: стандартная конфигурация; NAT: через iptables/nftables
VMware ESXi
Promiscuous mode, MAC changes, Forged transmits
Security policy на port group: Accept
Типовые симптомы
- L2-гость получает IP по DHCP, но не пингуется извне — MAC spoofing / promiscuous mode не включены.
- ARP-запросы не проходят — L0-свитч блокирует кадры с неизвестными MAC.
- Трафик виден только внутри L1 — L0-свитч или физический коммутатор фильтрует нестандартные MAC.
Подход к выбору
MAC spoofing / Promiscuous mode — проще в настройке, даёт прозрачный L2-доступ. Подходит для лабораторий. С точки зрения ИБ расширяет поверхность атаки — используйте только в изолированных сегментах.
NAT — не требует расширения прав на L0, но усложняет маршрутизацию и диагностику. Подходит, когда MAC spoofing запрещён политиками безопасности или облачным провайдером.
Какой вариант выбрать? Для корпоративной лаборатории на выделенном VLAN мы обычно рекомендуем MAC spoofing — он прозрачнее и проще в отладке. Для облачных стендов, где провайдер ограничивает L2-трафик, NAT остаётся единственным вариантом.
NAT — не требует расширения прав на L0, но усложняет маршрутизацию и диагностику. Подходит, когда MAC spoofing запрещён политиками безопасности или облачным провайдером.
Какой вариант выбрать? Для корпоративной лаборатории на выделенном VLAN мы обычно рекомендуем MAC spoofing — он прозрачнее и проще в отладке. Для облачных стендов, где провайдер ограничивает L2-трафик, NAT остаётся единственным вариантом.
Ограничения и влияние на производительность
Nested virtualization почти всегда снижает производительность и ограничивает часть функций гипервизора. По данным «Nested Virtualization in VMware ESXi and Hyper-V» от StarWind, 2024, каждый уровень вложения добавляет накладные расходы CPU и памяти. Основные потери проявляются в I/O, памяти, сетевой обработке и операциях, где происходит много VM-exit/VM-entry между L2, L1 и L0.
Microsoft в документации по nested Hyper-V предупреждает, что технология не подходит для производительно чувствительных приложений и имеет ограничения по Dynamic Memory, checkpoints и live migration. Broadcom указывает, что nested ESXi не предназначен для production. Но есть нюанс: степень деградации сильно зависит от профиля нагрузки.
Главные ограничения:
Microsoft в документации по nested Hyper-V предупреждает, что технология не подходит для производительно чувствительных приложений и имеет ограничения по Dynamic Memory, checkpoints и live migration. Broadcom указывает, что nested ESXi не предназначен для production. Но есть нюанс: степень деградации сильно зависит от профиля нагрузки.
Главные ограничения:
Область
Что происходит
Практический риск
CPU
Увеличивается число VM-exit/VM-entry
Compute-нагрузки работают медленнее, особенно при частых переключениях
Память
Добавляется двойная трансляция страниц EPT/NPT
Растёт overhead и давление на TLB
Storage I/O
Запрос проходит несколько уровней виртуальных устройств
Увеличивается latency, особенно на random I/O
Сеть
Трафик проходит через два vSwitch/bridge
Требуются MAC spoofing, promiscuous mode или NAT
Live migration
Поддержка ограничена или не гарантируется
Сложнее обслуживать кластер без простоя
Checkpoints/snapshots
В Hyper-V production checkpoints не поддерживаются для nested-сценариев
Риск неконсистентного восстановления
HA/FT/DRS
В VMware nested ESXi не рассчитан на production
Нельзя строить SLA на лабораторной функции
Host-level backup
Бэкап L0 не всегда понимает состояние L2
Нужно тестировать восстановление всей цепочки
В открытых вендорских материалах нет универсальной цифры потерь для Hyper-V, Proxmox/KVM и VMware ESXi — корректнее оценивать профиль конкретной нагрузки. В практических обсуждениях VMware-сообщества и материалах StarWind указывается, что compute-потери обычно менее заметны, чем деградация I/O, а каждый новый уровень вложения добавляет накладные расходы. Для точной оценки используйте инструменты: fio для storage, iperf3 для сети, stress-ng для CPU, Windows Performance Monitor для Windows-нагрузок.
Для лаборатории это приемлемо. Для production — далеко не всегда.
Типичный инженерный критерий: если стенд нужен для проверки установки, сетевой схемы, обновления гипервизора или обучения, nested virtualization экономит физические серверы. Если нужно измерить latency СХД, производительность СУБД, поведение 1С под нагрузкой или пропускную способность сети 25/100 Гбит/с — nested-стенд не заменяет тест на целевом железе. В этом контексте полезно знать подходы к P2V-миграции физического сервера, чтобы корректно переносить нагрузки между средами.
Также учитывайте безопасность. По данным «Microsoft Security Guidance on L1TF/MDS» от Microsoft, 2024, для виртуализации рекомендуются обновления микрокода, патчи ОС и core scheduler. Для nested virtualization это особенно важно, потому что добавляется ещё один гипервизорный уровень и расширяется поверхность атаки.
Для лаборатории это приемлемо. Для production — далеко не всегда.
Типичный инженерный критерий: если стенд нужен для проверки установки, сетевой схемы, обновления гипервизора или обучения, nested virtualization экономит физические серверы. Если нужно измерить latency СХД, производительность СУБД, поведение 1С под нагрузкой или пропускную способность сети 25/100 Гбит/с — nested-стенд не заменяет тест на целевом железе. В этом контексте полезно знать подходы к P2V-миграции физического сервера, чтобы корректно переносить нагрузки между средами.
Также учитывайте безопасность. По данным «Microsoft Security Guidance on L1TF/MDS» от Microsoft, 2024, для виртуализации рекомендуются обновления микрокода, патчи ОС и core scheduler. Для nested virtualization это особенно важно, потому что добавляется ещё один гипервизорный уровень и расширяется поверхность атаки.
Дисклеймер: если nested-стенд используется с персональными данными, соблюдайте требования 152-ФЗ «О персональных данных»: не используйте production-данные в лабораторных средах без обезличивания. Для организаций, подпадающих под 187-ФЗ «О безопасности КИИ», лабораторные стенды с nested virtualization должны быть изолированы от production-контуров критической информационной инфраструктуры. При использовании сертифицированных средств защиты информации проверяйте совместимость с nested-архитектурой по требованиям ФСТЭК.
Облачные оговорки
В публичных облаках (Azure, AWS, Yandex Cloud, VK Cloud) nested virtualization зависит от типа инстанса и политики провайдера. Не все типы ВМ поддерживают проброс VT-x/AMD-V. Перед развёртыванием лаборатории проверяйте документацию облачного провайдера — иначе рискуете потратить время на настройку, которая просто не сработает на выбранном инстансе.
Практический вывод: вложенную виртуализацию стоит использовать как инженерный инструмент, а не как универсальную production-архитектуру. Для Hyper-V, Proxmox, KVM и VMware ESXi сначала включите CPU-флаги и сетевые режимы, затем обязательно проверьте производительность, восстановление, бэкап и ограничения миграции на вашем сценарии.
Практический вывод: вложенную виртуализацию стоит использовать как инженерный инструмент, а не как универсальную production-архитектуру. Для Hyper-V, Proxmox, KVM и VMware ESXi сначала включите CPU-флаги и сетевые режимы, затем обязательно проверьте производительность, восстановление, бэкап и ограничения миграции на вашем сценарии.
Диагностика типовых проблем
Собрали в одну таблицу симптомы, с которыми чаще всего сталкиваются наши инженеры и заказчики при настройке nested virtualization.
Симптом
Вероятная причина
Как проверить
Что сделать
Внутри L1 не видны vmx или svm
CPU-флаги не проброшены
grep -E 'vmx|svm' /proc/cpuinfo
Включить CPU type host / host-passthrough / Expose virtualization extensions
Hyper-V внутри ВМ не устанавливается
Не видна аппаратная виртуализация
Get-VMProcessor → ExposeVirtualizationExtensions
Остановить ВМ, включить параметр на L0, проверить версию ОС
Dynamic Memory включена и ВМ не загружается
Hyper-V не поддерживает Dynamic Memory при nested
Проверить Get-VMMemory
Set-VMMemory -DynamicMemoryEnabled $false
Вложенные ВМ не имеют сети в Hyper-V
Не включён MAC spoofing
Проверить сетевой адаптер ВМ L1
Set-VMNetworkAdapter -MacAddressSpoofing On
L2-гости в ESXi не пингуются
Блокируются MAC-адреса L2
Проверить port group security policy
Включить Promiscuous/MAC changes/Forged transmits или MAC learning
nested=1, но KVM внутри L1 не стартует
ВМ L1 использует generic CPU model
Проверить XML/libvirt CPU mode
Установить host-passthrough
modprobe -r завершается ошибкой
На хосте работают ВМ
lsmod | grep kvm
Выключить все ВМ или запланировать перезагрузку
После изменения модуля KVM ничего не поменялось
Модуль не был перезагружен
Проверить /sys/module/.../nested
Перезагрузить модуль в maintenance window или перезагрузить хост
Производительность storage низкая
Двойной слой виртуального I/O
Проверить latency на L0/L1/L2 с помощью fio
Не использовать nested для замеров СХД и latency-sensitive workload
Live migration/checkpoint не работают
Ограничения nested-сценария
Сверить документацию гипервизора
Не проектировать production SLA на nested-функциях
BIOS/UEFI — VT-x/SVM отключены
Виртуализация не активирована на физическом сервере
Проверить настройки BIOS/UEFI
Включить Intel Virtualization Technology / SVM Mode
Что делать дальше
Если вы планируете лабораторию или PoC на базе nested virtualization:
Если нужен подбор серверного оборудования под лабораторию или PoC, аудит существующей инфраструктуры или помощь с развёртыванием кластера виртуализации — обращайтесь к нашей команде в Work System.
- Проверьте текущую инфраструктуру. Убедитесь, что CPU поддерживает VT-x/AMD-V с EPT/NPT, а BIOS/UEFI настроен корректно.
- Определите масштаб стенда. Сколько L2-гостей нужно, какие гипервизоры тестируете, нужна ли отказоустойчивость на уровне L1.
- Заложите ресурсы с запасом. Используйте sizing-таблицу из раздела выше как ориентир. Для стенда из трёх nested-гипервизоров с 2–3 L2-гостями на каждом закладывайте минимум 48 ГБ RAM и 12+ vCPU на L1-уровне.
- Изолируйте lab-сеть. Не включайте promiscuous mode и MAC spoofing на production-портах.
- Не экстраполируйте результаты. Nested-стенд показывает логику, но не даёт production-цифр по latency, IOPS и throughput.
Если нужен подбор серверного оборудования под лабораторию или PoC, аудит существующей инфраструктуры или помощь с развёртыванием кластера виртуализации — обращайтесь к нашей команде в Work System.
FAQ
Как правило, нет. Nested virtualization подходит для lab, обучения, PoC и проверки логики конфигураций. Для SLA-нагрузок, latency-тестов, СУБД, 1С и сетей 25/100 Гбит/с нужны тесты на целевой платформе без лишнего уровня вложения. Microsoft, Broadcom и Red Hat документируют nested virtualization как лабораторную функцию.
Чаще всего не включена виртуализация в BIOS/UEFI, не активирован nested mode на L0 или для ВМ L1 выбран CPU type без vmx/svm. Проверьте все три уровня: BIOS → настройка гипервизора L0 → CPU type ВМ.
Нужны оба ресурса, но в лабораториях быстрее заканчивается RAM: память нужна L0-гипервизору, L1-гипервизору и всем L2-гостям одновременно. На практике именно нехватка оперативной памяти становится первым «бутылочным горлышком».
Потому что L2-гости используют MAC-адреса, отличные от MAC ВМ L1. Для Hyper-V проверьте MAC Address Spoofing, для ESXi — Promiscuous mode, MAC address changes и Forged transmits, для KVM/Proxmox — конфигурацию Linux bridge и MAC-фильтрации.
Да, если это поддерживают CPU, BIOS/UEFI, версия гипервизора L0 и гостевая ОС. Для Hyper-V на AMD требуется Windows Server 2022 / Windows 11 или новее. Ранние материалы 2015 года утверждали «только Intel» — это устаревшая информация.
Proxmox использует KVM/QEMU, поэтому базовая механика та же: nested mode в модуле ядра и проброс CPU-флагов в ВМ. Отличие — в GUI, управлении через qm set и конфигурации /etc/pve/qemu-server/<VMID>.conf. По сути, Proxmox — это удобная обёртка над KVM с веб-интерфейсом и кластерными функциями.
Нет, VT-d и IOMMU нужны для PCI/PCIe passthrough, а не для nested virtualization. Для nested достаточно VT-x/AMD-V с EPT/NPT. Однако если внутри L1 планируется passthrough-устройств в L2, ситуация усложняется и зависит от конкретной платформы — в большинстве случаев такой сценарий не поддерживается.
Ограниченно. Live migration для nested Hyper-V документирована с ограничениями. В VMware ESXi nested-сценарий не гарантирует vMotion. В KVM host-passthrough ухудшает переносимость между хостами с разными поколениями CPU. Планируйте миграцию с тестированием на конкретной инфраструктуре — универсального рецепта здесь нет.