Вы включили VT-x или AMD-V в BIOS/UEFI, но гипервизор упорно сообщает, что аппаратная виртуализация недоступна. VMware Workstation, VirtualBox или KVM отказываются запускать виртуальные машины. Эта проблема распространена и редко связана с одной причиной. Чаще всего активация в BIOS - лишь первый шаг. Конфликты возникают на уровне операционной системы из-за функций безопасности, устаревшего микрокода процессора или специфичных настроек самого гипервизора.
Основные «виновники» известны: технологии безопасности Windows, такие как Credential Guard и Hypervisor-Enforced Code Integrity (HVCI), которые монопольно используют гипервизор. Аналогичные функции на уровне CPU - Intel SGX или AMD SEV - также могут блокировать доступ. Устаревшая версия микрокода или прошивки BIOS/UEFI иногда содержит ошибки, мешающие работе виртуализации. Наконец, для гипервизоров вроде KVM на Linux требуются дополнительные параметры ядра, например, для включения вложенной виртуализации.
Почему гипервизор не видит виртуализацию, даже если она включена в BIOS?
Активация опции Intel VT-x, AMD-V или SVM Mode в BIOS/UEFI - это разрешение процессору использовать свои аппаратные расширения для виртуализации. Однако операционная система или гипервизор могут не получить к ним доступ. Проблема носит системный характер.
В Windows 10 и 11 функции безопасности, основанные на виртуализации, часто запускаются по умолчанию. Hypervisor-Enforced Code Integrity (также известная как Memory Integrity) и Credential Guard для своей работы задействуют гипервизор Hyper-V. Когда Hyper-V активен как базовый уровень, другие гипервизоры типа VMware или VirtualBox не могут получить прямой доступ к VT-x/AMD-V. Это архитектурное ограничение.
На уровне процессора технологии вроде Intel Software Guard Extensions (SGX) или AMD Secure Encrypted Virtualization (SEV) также используют изолированные среды выполнения. Они могут конфликтовать за аппаратные ресурсы с гипервизорами общего назначения.
Микрокод CPU - это низкоуровневое программное обеспечение, которое исправляет ошибки и управляет функциями процессора. Устаревший микрокод может содержать баги, нарушающие работу VT-x/AMD-V. Обновление микрокода часто решает неочевидные проблемы с виртуализацией.
Наконец, сами гипервизоры требуют правильной конфигурации. Для KVM в Linux может потребоваться явная загрузка модулей kvm_intel или kvm_amd и включение параметра kvm-intel.nested=1 для вложенной виртуализации. VMware Workstation имеет настройки виртуализационного движка, которые нужно проверить.
Полный алгоритм диагностики: от BIOS до гипервизора
Следуйте этому плану, чтобы локализовать проблему. Действуйте последовательно, проверяя каждый слой.
Шаг 1: Убедиться, что настройки BIOS/UEFI сохранены и активны
Перезагрузите компьютер и войдите в интерфейс прошивки (клавиши Del, F2, F10). Найдите раздел, связанный с процессором: обычно Advanced -> CPU Configuration или Advanced CPU Core Settings.
Ищите опции с разными названиями:
- Для Intel: Intel Virtualization Technology, Intel VT-x, VT-d (для прямой передачи ввода-вывода).
- Для AMD: SVM Mode, AMD-V.
Убедитесь, что значение установлено в Enabled. После изменения обязательно выберите Save Changes and Exit или аналогичный пункт. Простая перезагрузка без сохранения не активирует настройки.
Шаг 2: Проверка поддержки виртуализации в ОС (Windows и Linux)
После загрузки системы выполните команды для проверки состояния.
В Windows откройте командную строку или PowerShell от имени администратора.
Выполните команду systeminfo. В большом выводе найдите две ключевые строки:
Virtualization Enabled In Firmware: Yes/No
Hyper-V Requirements: ...
Если в первой строке No, проблема на уровне BIOS/UEFI. Вторая строка покажет состояние компонентов Hyper-V. Любая пометка «No» указывает на конфликт.
Для детального анализа флагов процессора используйте утилиту coreinfo от Sysinternals. Скачайте ее и запустите в терминале: coreinfo -v. В выводе для Intel ищите строку с VMX, для AMD - SVM. Их наличие подтверждает поддержку процессором.
В Linux откройте терминал. Выполните команду:
lscpu | grep Virtualization
Или для детального просмотра всех флагов:
cat /proc/cpuinfo | grep flags
В выводе ищите флаг vmx (Intel) или svm (AMD). Его отсутствие означает, что ОС не видит поддержку виртуализации.
Шаг 3: Интерпретация результатов диагностики
Результаты команд дают четкие указания:
Virtualization Enabled In Firmware: No- функция отключена в BIOS/UEFI или изменения не сохранены. Вернитесь к Шагу 1.- В строке
Hyper-V Requirementsесть пункты с «No» - например, «A hypervisor has been detected. Features required for Hyper-V will not be displayed». Это явный признак конфликта: гипервизор уже работает (часто это функции безопасности). Переходите к разделу о решении конфликтов. - Флаги
vmx/svmотсутствуют вlscpuилиcoreinfo- при корректном BIOS это указывает на проблему с процессором (отсутствие поддержки) или на необходимость обновления микрокода.
Если вы ищете более глубокий разбор подобных сценариев, в нашей базе знаний есть подробное руководство по диагностике неочевидных проблем с VT-x/AMD-V.
Решение конфликтов с технологиями безопасности
Функции безопасности Windows - самая частая причина блокировки сторонних гипервизоров.
Отключение Hypervisor-Enforced Code Integrity (HVCI) и Memory Integrity
Эта функция, часть Windows Security, использует гипервизор для изоляции процессов.
- Откройте «Параметры Windows» -> «Обновление и безопасность» -> «Безопасность Windows».
- Выберите «Безопасность устройства».
- В разделе «Изоляция ядра» найдите «Целостность памяти». Если переключатель активен, выключите его. Система запросит перезагрузку.
Альтернативный способ через PowerShell (от администратора):
Disable-WindowsOptionalFeature -Online -FeatureName Windows-Defender-ApplicationGuard
Перезагрузите компьютер. После этого гипервизоры типа VMware должны получить доступ к VT-x/AMD-V. Помните, это временно снижает уровень безопасности системы.
Как проверить и отключить Credential Guard
Credential Guard (Device Guard) изолирует секреты в защищенной среде на основе Hyper-V.
Проверьте ее состояние. В командной строке снова выполните systeminfo. Если в разделе «Hyper-V Requirements» вы видите «Credential Guard is enabled», функция активна.
Для отключения есть несколько методов. Самый надежный - через реестр.
- Нажмите Win+R, введите
regedit. - Перейдите по пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. - Найдите параметр
LsaCfgFlagsтипа DWORD. Если его нет, создайте. - Установите значение
0для отключения всех функций изоляции. - Перезагрузите компьютер.
Также можно использовать официальный инструмент Microsoft DGReadinessTool с ключом -Disable или настроить групповые политики (Политика локального компьютера -> Административные шаблоны -> Система -> Device Guard).
Аналогичные конфликты могут создавать технологии на уровне CPU: Intel SGX и AMD SEV. Их обычно отключают в том же разделе BIOS/UEFI, где включают виртуализацию. Найдите опции Intel SGX Enable или AMD SEV и установите в Disabled.
Обновление микрокода CPU и прошивки BIOS/UEFI
Микрокод - это набор инструкций, которые загружаются в процессор при старте системы. Он исправляет ошибки и может влиять на работу виртуализации.
Как проверить версию микрокода в Windows:
- Откройте «Диспетчер устройств».
- Раскройте «Процессоры», щелкните правой кнопкой по вашему CPU и выберите «Свойства».
- На вкладке «Драйвер» посмотрите версию драйвера. Часто она соответствует версии микрокода. Более точно покажет утилита CPU-Z на вкладке «CPU» в поле «Revision».
Как проверить версию микрокода в Linux:
dmesg | grep microcode
Или:
cat /proc/cpuinfo | grep microcode
Обновление микрокода:
- Через BIOS/UEFI: Посетите сайт производителя вашей материнской платы (ASUS, Gigabyte, MSI) или ноутбука (Dell, HP, Lenovo). Найдите модель, скачайте последнюю версию прошивки. Обновление BIOS обычно включает и актуальный микрокод. Следуйте инструкциям производителя строго - ошибка может вывести плату из строя.
- Через ОС в Linux: Установите пакет микрокода. Для Intel:
sudo apt install intel-microcode(Debian/Ubuntu). Для AMD:sudo apt install amd64-microcode. После установки перезагрузите систему. - В Windows микрокод часто обновляется через центры обновления Windows или драйверы чипсета от производителя.
Если вы столкнулись с проблемами на конкретном оборудовании, например, материнских платах Gigabyte, вам поможет специализированное руководство по виртуализации на серверах Gigabyte.
Специфичные настройки для разных гипервизоров
После устранения конфликтов на уровне BIOS и ОС проверьте настройки самого гипервизора.
Настройка KVM и вложенной виртуализации (nested virtualization)
Для работы KVM в Linux должны быть загружены соответствующие модули ядра.
Проверьте это командой:
lsmod | grep kvm
Вы должны увидеть kvm_intel или kvm_amd, а также kvm. Если модули отсутствуют, загрузите их:
sudo modprobe kvm_intel # для Intel
# или
sudo modprobe kvm_amd # для AMD
Для включения вложенной виртуализации (запуск KVM внутри KVM) необходимо изменить параметры ядра.
- Откройте файл конфигурации Grub:
sudo nano /etc/default/grub. - Найдите строку
GRUB_CMDLINE_LINUX_DEFAULT. - Внутри кавычек добавьте параметр:
Для Intel:kvm-intel.nested=1
Для AMD:kvm-amd.nested=1 - Сохраните файл (Ctrl+O, Enter) и закройте (Ctrl+X).
- Обновите конфигурацию Grub:
sudo update-grub(Debian/Ubuntu)
sudo grub2-mkconfig -o /boot/grub2/grub.cfg(RHEL/CentOS/Fedora) - Перезагрузите систему.
- Проверьте активацию:
cat /sys/module/kvm_intel/parameters/nested(должно быть Y или 1).
Проверка настроек VMware и Hyper-V
VMware Workstation/Player:
- Перейдите в Edit -> Preferences.
- Выберите вкладку Advanced.
- В разделе Virtualization engine убедитесь, что выбрано:
«Intel VT-x/EPT or AMD-V/RVI». - Также проверьте, что не стоит галочка «Virtualize Intel VT-x/EPT or AMD-V/RVI» (это для вложенной виртуализации внутри гостевой ОС).
Hyper-V:
- Убедитесь, что роль «Hyper-V» установлена в системе. Проверьте через «Панель управления -> Программы и компоненты -> Включение или отключение компонентов Windows».
- Откройте «Диспетчер Hyper-V».
- Убедитесь, что создан хотя бы один виртуальный коммутатор (в меню «Действия» -> «Диспетчер виртуальных коммутаторов»). Без него виртуальные машины не смогут работать с сетью.
Для быстрой проверки состояния виртуализации в разных средах используйте нашу шпаргалку с готовыми командами для Windows и Linux.
Дополнительные проверки и частые ошибки
Если все предыдущие шаги не помогли, пройдите этот контрольный список.
- Разрядность ОС: Аппаратная виртуализация требует 64-битной операционной системы. Запуск 64-битных гостевых ОС невозможен под 32-битной хостовой системой, даже если процессор поддерживает VT-x/AMD-V.
- Версия гипервизора: Установите последнюю версию VMware, VirtualBox или используйте актуальные репозитории для KVM. В старых версиях могут быть баги.
- Режим совместимости: Проверьте, не запускаете ли вы гипервизор в режиме совместимости с более ранними версиями Windows. Это может блокировать доступ к низкоуровневым функциям.
- Функция «Windows Hypervisor Platform»: Этот дополнительный компонент Windows (отдельный от Hyper-V) нужен для WSL2 и некоторых других сценариев. Его включение также может создавать конфликты. Попробуйте отключить его в «Компонентах Windows».
- Поддержка процессором: Убедитесь, что ваш процессор физически поддерживает VT-x (Intel) или AMD-V. Старые модели (некоторые ранние Core 2 Duo, бюджетные Celeron/Pentium) могут не иметь этой функции. Проверьте спецификации на ark.intel.com или у AMD.
- Антивирусы: Некоторые антивирусные решения, особенно с функциями эмуляции или песочницы, могут перехватывать управление виртуализацией. Попробуйте временно отключить антивирус для теста.
Если вы выполнили все шаги алгоритма, но проблема сохраняется, возможны редкие сценарии: физическая неисправность процессора, повреждение прошивки BIOS/UEFI или крайне специфичный конфликт драйверов чипсета. В таких случаях может потребоваться сброс BIOS к настройкам по умолчанию, перепрошивка или тестирование на другом оборудовании.
Для комплексного подхода к настройке виртуализационных сред, включая выбор правильного гипервизора и тонкую настройку производительности, рекомендуем ознакомиться с нашими другими материалами, например, полным руководством по включению виртуализации для VMware и VirtualBox.
Если вам нужно не только решать проблемы, но и эффективно работать с различными AI-моделями для автоматизации задач, обратите внимание на сервис AiTunnel. Этот агрегатор API предоставляет единый интерфейс для доступа к более чем 200 моделям, включая GPT, Gemini и Claude, с оплатой в рублях и без необходимости использования VPN.