Как включить вложенную виртуализацию в VMware и ESXi

Где включается вложенная виртуализация в VMware

Вложенная виртуализация в VMware включается в одном из трёх мест, и все три меняют одну и ту же настройку. В VMware Workstation это галочка Virtualize Intel VT-x/EPT or AMD-V/RVI в параметрах процессора виртуальной машины. В ESXi это галочка Expose hardware assisted virtualization to the guest OS в разделе CPU. Под обеими лежит одна строка в файле .vmx: vhv.enable = "TRUE".

Иногда галочка стоит, а машина не запускается с ошибкой Virtualized Intel VT-x/EPT is not supported on this platform. Тогда причина почти всегда в хосте на Windows. Аппаратную виртуализацию там уже занял гипервизор Microsoft, и Workstation нечего передать гостю. Этой ошибке посвящена большая часть статьи.

Зачем гостю аппаратная виртуализация

Типичная ситуация: на рабочем компьютере стоит Windows и VMware Workstation. Нужно поднять стенд с Proxmox VE, попробовать KVM (kernel-based virtual machine, гипервизор в ядре Linux) или собрать лабораторию из нескольких вложенных ESXi под vCenter. Другая ситуация: в серверной ещё работает старый ESXi, и на нём нужна тестовая ВМ с Hyper-V или WSL2. В обоих случаях гостевой системе нужны инструкции аппаратной виртуализации процессора.

У Intel это VT-x (Intel Virtualization Technology) и EPT (extended page tables, аппаратная трансляция адресов памяти гостя). У AMD это AMD-V и RVI (rapid virtualization indexing), аналог EPT. По умолчанию VMware скрывает эти возможности от гостя. Гость видит процессор без VT-x, поэтому KVM внутри не загружается, а роль Hyper-V не ставится. В документации VMware включение этой функции называется VHV (virtualized hardware virtualization). Гипервизор показывает гостю VT-x или AMD-V и сам обслуживает эти инструкции поверх настоящих.

Чем вложенная машина отличается от обычной по скорости и когда она вообще имеет смысл, подробно разобрано в статье о вложенной виртуализации на VPS. Здесь речь только о продуктах VMware.

VMware Workstation: галочка в настройках процессора

Эта настройка есть в Workstation Pro версий 15.x, 16.x и 17.x. К этим же версиям Broadcom относит ошибку, которая разобрана ниже. Названия пунктов даны по английскому интерфейсу Workstation.

1. Выключите ВМ полностью. Приостановить (suspend) машину недостаточно: у приостановленной ВМ настройки процессора менять нельзя.
2. Откройте VM > Settings > Hardware > Processors.
3. В блоке Virtualization engine поставьте галочку Virtualize Intel VT-x/EPT or AMD-V/RVI.
4. Нажмите OK и запустите ВМ.

В том же блоке есть ещё две галочки. Virtualize CPU performance counters нужна только профилировщикам внутри гостя. Virtualize IOMMU (IO memory management unit) нужна, если внутри гостя вы будете пробрасывать устройства или включать VBS в гостевой Windows. Для KVM или Proxmox VE достаточно первой галочки.

На Linux-хосте Hyper-V нет, поэтому обычно этого шага хватает. Если ВМ всё равно не стартует, проверьте, что VT-x или AMD-V включены в BIOS/UEFI самого компьютера. Команда grep -cE 'vmx|svm' /proc/cpuinfo на хосте должна вернуть число больше нуля.

ESXi: Expose hardware assisted virtualization to the guest OS

В ESXi та же настройка задаётся для каждой ВМ отдельно. Она работает при версии виртуального оборудования (virtual hardware version) 9 или выше. Версия 9 появилась в ESXi 5.1, поэтому на любом ESXi, который ещё встречается в серверных, она доступна. Если машина создана очень давно и версия у неё ниже 9, сначала поднимите совместимость: правый клик по ВМ, Compatibility > Upgrade VM Compatibility.

1. Выключите ВМ.
2. В vSphere Client сделайте правый клик по ВМ и выберите Edit Settings. В веб-интерфейсе самого хоста (ESXi Host Client) пункт называется так же.
3. Раскройте раздел CPU.
4. Поставьте галочку Expose hardware assisted virtualization to the guest OS.
5. Нажмите OK и включите ВМ.

Если галочка серая, обычно машина не выключена или у неё слишком старая версия оборудования.

Эта же галочка нужна, когда внутри Windows-ВМ на ESXi запускают сам VMware Workstation. Без неё Workstation в госте не включает машины и пишет:

This host appears to be running in a virtual machine with VHV disabled.

Этот случай описан в третьей части статьи Broadcom KB 389469.

Строка vhv.enable в файле .vmx

Обе галочки записывают в конфигурацию ВМ одну строку. Файл .vmx лежит в каталоге машины. У Workstation на Windows по умолчанию это Documents\Virtual Machines\<имя ВМ>, на Linux это ~/vmware/<имя ВМ>. У ESXi это каталог ВМ на datastore.

vhv.enable = "TRUE"

Править файл руками удобно, когда нужно включить вложенность сразу на десятке машин или когда вы готовите шаблон скриптом. Правило одно: ВМ должна быть выключена, а в Workstation её вкладка должна быть закрыта. Иначе Workstation при закрытии запишет .vmx из своей памяти, и ваша правка пропадёт.

На ESXi после ручной правки хост должен перечитать конфигурацию. В SSH-сессии на хосте найдите идентификатор машины командой vim-cmd vmsvc/getallvms. Затем выполните vim-cmd vmsvc/reload с этим идентификатором. Проще поставить галочку в интерфейсе: результат тот же.

Почему Workstation пишет «Virtualized Intel VT-x/EPT is not supported on this platform»

Самый частый случай на Windows 10 и 11 выглядит так. Галочка стоит, а при запуске ВМ появляется ошибка:

Virtualized Intel VT-x/EPT is not supported on this platform.

Иногда рядом появляется сообщение о том, что Workstation несовместим с Device/Credential Guard. Broadcom описывает оба симптома в KB 389469.

Причина: на хосте уже работает гипервизор Microsoft. Запускает его не только роль Hyper-V. Он стартует при загрузке Windows, если включено хотя бы одно из следующего:

• компонент Hyper-V;
• «Платформа виртуальной машины» (Virtual Machine Platform), на ней работают WSL2 и Docker Desktop с бэкендом WSL2;
• «Платформа низкоуровневой оболочки Windows» (Windows Hypervisor Platform);
• «Песочница Windows» (Windows Sandbox);
• VBS (virtualization-based security, безопасность на основе виртуализации), в том числе «Целостность памяти» (Memory integrity).

Когда гипервизор Microsoft запущен, VT-x принадлежит ему. Workstation начиная с версии 15.5.5 в такой ситуации не отказывается работать: он запускает ВМ через API Hyper-V. Но в этом режиме Workstation сам является гостем чужого гипервизора. Передать VT-x своей ВМ он не может, потому что сам его не получил. Отсюда ошибка.

Как проверить режим монитора в vmware.log

Workstation записывает режим работы в vmware.log в каталоге каждой ВМ. Снимите галочку VT-x, запустите машину и найдите строку Monitor Mode. В PowerShell это делается так:

Select-String -Path "$env:USERPROFILE\Documents\Virtual Machines\*\vmware.log" -Pattern "Monitor Mode"

По KB 389469 значение CPL0 означает, что Workstation работает с процессором напрямую, и вложенная виртуализация возможна. Значение UML означает, что используется API Hyper-V. В этом режиме галочка VT-x работать не будет, пока гипервизор Microsoft не выключен.

Состояние VBS показывает отдельный запрос:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning

Значение 2 в VirtualizationBasedSecurityStatus означает, что VBS запущена. Число 2 в списке SecurityServicesRunning означает, что работает «Целостность памяти». Те же сведения есть в окне msinfo32, в строках про безопасность на основе виртуализации.

Как выключить гипервизор Microsoft

Шаги ниже взяты из KB 389469. Делайте их по порядку и проверяйте Monitor Mode после перезагрузки.

Первый шаг: откройте «Безопасность Windows», затем «Безопасность устройства» и «Изоляция ядра» (Core isolation). Выключите переключатель «Целостность памяти».

Второй шаг: откройте «Включение или отключение компонентов Windows» (optionalfeatures.exe). Снимите галочки Hyper-V, «Платформа виртуальной машины», «Платформа низкоуровневой оболочки Windows» и «Песочница Windows».

Третий шаг: в консоли, запущенной от имени администратора, запретите загрузку гипервизора:

bcdedit /set hypervisorlaunchtype off

Четвёртый шаг нужен, если VBS включена через реестр. Задайте значение 0:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f

Последний шаг: перезагрузите компьютер. Без перезагрузки ничего не изменится, потому что гипервизор Microsoft запускается на этапе загрузки системы.

После перезагрузки снова найдите Monitor Mode в свежем vmware.log. Нужно значение CPL0. Если там по-прежнему UML, гипервизор всё ещё кто-то запускает: перепроверьте список компонентов и вывод Get-CimInstance. Набор компонентов, которые поднимают гипервизор, менялся между сборками Windows 10 и 11. Здесь перечислено то, что называет Broadcom. За сборку, которую мы не проверяли, ручаться нельзя. После крупного обновления Windows проверьте Monitor Mode ещё раз.

Чтобы вернуть всё назад, выполните bcdedit /set hypervisorlaunchtype auto, включите компоненты и «Целостность памяти», затем перезагрузитесь.

Учтите цену. Пока гипервизор Microsoft выключен, не работают WSL2, Docker Desktop с бэкендом WSL2, Windows Sandbox и сам Hyper-V. Придётся выбирать: либо они, либо вложенный VT-x в Workstation. Если WSL2 нужен каждый день, стенд с KVM удобнее держать не на ноутбуке, а на отдельном сервере.

Что стоит отключение «Целостности памяти»

«Целостность памяти» (в документации Microsoft HVCI, hypervisor-protected code integrity) использует гипервизор, чтобы проверять код драйверов режима ядра до его запуска. Само ядро Windows не может сделать страницу памяти исполняемой. Это решает изолированный компонент, который проверяет подпись кода. Поэтому уязвимый или вредоносный драйвер не может просто записать свой код в память ядра и выполнить его. Когда вы выключаете защиту, этот барьер исчезает. Система работает как раньше, но атака через драйвер становится проще.

Вместе с VBS перестаёт работать Credential Guard, если он был включён. Он хранит секреты LSA (local security authority), то есть хеши NTLM и билеты Kerberos, в изолированной среде. Оттуда их не достать даже с правами администратора в обычной системе. В домашних редакциях Windows Credential Guard нет. На корпоративном ноутбуке VBS часто включена политикой, и тогда переключатель «Целостность памяти» может быть неактивен. В этом случае не обходите политику через реестр. Попросите у отдела безопасности отдельную машину для стенда или поднимите стенд на сервере.

Вложенный ESXi: почему его ВМ не видят сеть

Вложенный ESXi запускается, ВМ внутри него создаются, но сеть у них не работает. Адрес по DHCP не приходит, шлюз не пингуется. Дело не во вложенном хосте, а в политиках безопасности внешнего коммутатора.

Вложенный ESXi подключён к внешнему коммутатору одной виртуальной сетевой картой с одним MAC-адресом. Его собственные ВМ отправляют кадры со своими MAC-адресами. Внешний коммутатор видит кадры, у которых адрес отправителя не совпадает с MAC карты. Если политика Forged transmits стоит в Reject, такие кадры отбрасываются. В обратную сторону внешний коммутатор доставляет вложенному ESXi только кадры для MAC его карты. Ответы для вложенных ВМ до него не доходят, пока Promiscuous mode стоит в Reject.

Решение для стандартного коммутатора: на порт-группе, к которой подключён вложенный ESXi, поставьте Promiscuous mode и Forged transmits в Accept. В vSphere Client это раздел Security в настройках порт-группы. У этого решения есть цена. В режиме promiscuous каждая карта в порт-группе получает копию всего трафика группы. Это лишняя нагрузка на процессор, и чужой трафик становится виден. Поэтому заведите для вложенных ESXi отдельную порт-группу и не держите в ней обычные ВМ.

На распределённом коммутаторе (vSphere Distributed Switch) начиная с vSphere 6.7 есть MAC learning. Порт запоминает MAC-адреса, которые находятся за ним, как это делает физический коммутатор. Тогда promiscuous mode не нужен, и лишних копий трафика нет. Точный набор параметров для вашей версии vSphere сверьте с документацией VMware.

Если внешний гипервизор это Workstation на Linux-хосте, ограничение другое. Гость может включить promiscuous mode только при праве записи в устройство /dev/vmnet*, а по умолчанию это право есть только у root. Workstation пишет об отказе в журнал ВМ. Временно это решает sudo chmod a+rw /dev/vmnet0, но права могут сброситься после перезагрузки или перезапуска служб VMware.

Как проверить из Linux-гостя, что вложенность работает

После включения настройки проверьте результат изнутри гостя. Команды ниже подходят для Ubuntu и Debian, а значит и для Proxmox VE. Выполните их сами и смотрите на свой вывод.

grep -cE 'vmx|svm' /proc/cpuinfo
ls -l /dev/kvm
sudo apt install -y cpu-checker
sudo kvm-ok

Первая команда считает строки с флагом vmx (Intel) или svm (AMD). Такая строка есть у каждого логического процессора. Ноль означает, что гость не видит VT-x или AMD-V. Значит, настройка не применилась, или Workstation на хосте с Windows работает в режиме UML.

Вторая команда проверяет устройство /dev/kvm. Оно появляется, только когда модуль kvm_intel или kvm_amd загрузился. Если флаги есть, а устройства нет, посмотрите lsmod | grep kvm и sudo dmesg | grep -i kvm. Там будет причина, по которой модуль не загрузился.

Третья и четвёртая команды ставят пакет cpu-checker и запускают из него kvm-ok. Эта утилита сводит обе проверки в один ответ: можно ли в этой системе использовать ускорение KVM.

В Proxmox VE отсутствие вложенности проявляется при запуске любой ВМ с включённым KVM:

KVM virtualisation configured, but not available. Either disable in VM configuration or enable in BIOS.

Ошибка подсказывает выключить KVM в настройках ВМ. Не делайте этого: без KVM Proxmox эмулирует процессор программно, и машина работает намного медленнее. Правильно включить вложенность на уровне VMware. Если внутри Proxmox вы будете запускать ещё один гипервизор, следующий уровень включается уже в самом Proxmox. Это описано в статье как включить вложенную виртуализацию в Proxmox.

Если гость это арендованный VPS

Всё выше относится к VMware, которым вы управляете сами: к Workstation на своём компьютере или к ESXi на работе. У арендованного VPS такой галочки нет. Вложенность там включает провайдер на своём гипервизоре, и чаще всего это KVM, а не VMware. Узнать, доступна ли она на вашем тарифе, и проверить её теми же командами из гостя поможет статья о вложенной виртуализации на VPS.

Если вы ещё выбираете, где держать стенд, полезны две статьи. Разница между типами виртуализации у провайдеров описана в сравнении KVM, Xen и LXC на VPS. На контейнерной виртуализации вложенности не бывает. Выбор между своим сервером и арендой разобран в статье Proxmox на своём железе или VPS. А если /dev/kvm в госте уже есть, на нём работают не только полноценные ВМ, но и микро-ВМ Firecracker.

FAQ

Где в VMware Workstation включить вложенную виртуализацию?

Выключите ВМ и откройте VM > Settings > Hardware > Processors. В блоке Virtualization engine поставьте галочку Virtualize Intel VT-x/EPT or AMD-V/RVI. Галочка записывает в файл .vmx строку vhv.enable = "TRUE". В ESXi та же настройка называется Expose hardware assisted virtualization to the guest OS и находится в разделе CPU свойств ВМ. Для неё нужна версия виртуального оборудования 9 или выше.

Почему Workstation пишет «Virtualized Intel VT-x/EPT is not supported on this platform»?

На хосте с Windows уже работает гипервизор Microsoft. Его запускают Hyper-V, «Платформа виртуальной машины» для WSL2, Windows Sandbox или VBS с «Целостностью памяти». Тогда Workstation работает через API Hyper-V (в vmware.log строка Monitor Mode показывает UML) и не может передать VT-x гостю. Broadcom описывает решение в KB 389469: выключить «Целостность памяти» и эти компоненты, выполнить bcdedit /set hypervisorlaunchtype off и перезагрузиться.

Можно ли оставить WSL2 и одновременно включить вложенную виртуализацию в Workstation?

Нет. WSL2 работает на «Платформе виртуальной машины», а она запускает гипервизор Microsoft. Пока он запущен, Workstation работает в режиме UML, и вложенный VT-x недоступен. Придётся выбрать что-то одно или перенести стенд с KVM на отдельный сервер.

Как проверить внутри Linux-гостя, что вложенная виртуализация работает?

Выполните grep -cE 'vmx|svm' /proc/cpuinfo. Ноль означает, что гость не видит VT-x или AMD-V. Затем проверьте, что существует /dev/kvm. На Ubuntu и Debian установите пакет cpu-checker и запустите sudo kvm-ok. Утилита ответит, можно ли использовать ускорение KVM.

Почему ВМ внутри вложенного ESXi не получают сеть?

Внешний коммутатор отбрасывает кадры с MAC-адресами вложенных ВМ, потому что они не совпадают с MAC сетевой карты вложенного ESXi. На порт-группе вложенного ESXi поставьте Promiscuous mode и Forged transmits в Accept. Для вложенных ESXi лучше выделить отдельную порт-группу. На vSphere Distributed Switch начиная с vSphere 6.7 вместо promiscuous mode можно использовать MAC learning.