Вы включили виртуализацию в BIOS/UEFI, но VMware Workstation, VirtualBox или KVM всё равно сообщают, что «VT-x/AMD-V недоступен». Эта проблема может быть вызвана не аппаратными ограничениями, а конфликтами на уровне операционной системы, технологиями безопасности или даже устаревшим микрокодом процессора. В этом руководстве мы системно разберем причины и предоставим готовые команды для диагностики в Windows и Linux, а также пошаговые инструкции по устранению каждой из них.
Быстрая диагностика: проверяем состояние виртуализации в системе
Перед глубоким анализом убедитесь, что проблема действительно существует на уровне ОС. Эти команды помогут быстро подтвердить или исключить основные причины.
Команды для Windows: systeminfo, PowerShell и диспетчер задач
1. Проверка через systeminfo: Откройте командную строку или PowerShell и выполните:
systeminfo | findstr /I "Hyper-V"Если в выводе есть строки «Hyper-V Requirements: Virtualization Enabled In Firmware: Yes» и «A hypervisor has been detected. Features required for Hyper-V will not be displayed», значит гипервизор (часто Hyper-V) активен и блокирует доступ к VT-x/AMD-V для других программ.
2. Проверка через PowerShell: Для точного определения состояния компонентов Hyper-V используйте:
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-VСтатус «Enabled» подтверждает, что Hyper-V установлен и работает.
3. Проверка в диспетчере задач: Откройте «Диспетчер задач» → «Производительность» → «ЦП». Если в нижней части окна указано «Виртуализация: Используется», это также сигнализирует о активности гипервизора.
4. Скрипт для проверки изоляции ядра и VBS: Создайте и запустите PowerShell-скрипт для проверки функций безопасности Windows, которые могут блокировать виртуализацию:
$vbsStatus = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
if ($vbsStatus -ne $null) {
Write-Host "Virtualization-based Security (VBS) активен. Это может блокировать VT-x/AMD-V."
} else {
Write-Host "VBS не активен или не поддерживается."
}Проверка в Linux: флаги процессора и утилита kvm-ok
1. Проверка флагов CPU: Выполните команду для проверки поддержки виртуализации на уровне процессора:
grep -E "(vmx|svm)" /proc/cpuinfoНаличие флага vmx (для Intel) или svm (для AMD) в выводе указывает на аппаратную поддержку. Если флаги отсутствуют, проблема может быть в BIOS/UEFI или микрокоде.
2. Установка и запуск kvm-ok: Утилита kvm-ok из пакета cpu-checker дает более четкий ответ. Установите её и запустите:
sudo apt-get install cpu-checker # для Debian/Ubuntu
sudo kvm-okОна сообщит: «INFO: /dev/kvm exists» и «KVM acceleration can be used», если всё настроено правильно, или выявит конкретные препятствия.
3. Проверка загруженных модулей ядра: Убедитесь, что модуль KVM загружен:
lsmod | grep kvmНаличие строк kvm_intel или kvm_amd подтверждает готовность ядра к виртуализации.
Причина 1: Конфликт с компонентами виртуализации Windows (Hyper-V, WSL2, Sandbox)
Hyper-V является гипервизором типа 1 (работает непосредственно на аппаратном обеспечении). Когда он активен, он монополизирует доступ к функциям VT-x/AMD-V, делая их недоступными для гипервизоров типа 2, таких как VMware Workstation или VirtualBox. Это самая распространенная причина проблемы после обновлений Windows.
Как полностью отключить Hyper-V и связанные функции
1. Отключение через графический интерфейс: Откройте «Панель управления» → «Программы» → «Программы и компоненты» → «Включение или отключение компонентов Windows». Найдите и полностью отключите следующие компоненты:
• Hyper-V
• Windows Subsystem for Linux (WSL2, если используется)
• Windows Sandbox
• Virtual Machine Platform
2. Команды PowerShell для полного отключения: Для гарантированного результата выполните в PowerShell с правами администратора:
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatformПосле этого обязательно перезагрузите систему.
3. Проверка отключения в BIOS: После деактивации Hyper-V иногда требуется повторно проверить и убедиться, что VT-x/AMD-V всё ещё включены в BIOS/UEFI, хотя это обычно не меняется.
WSL2, Sandbox и безопасность: точечная настройка вместо полного отключения
Если вам необходимы WSL2 или Sandbox, полное отключение Hyper-V невозможно. Вместо этого можно настроить альтернативные режимы работы.
1. Настройка VirtualBox для работы поверх Hyper-V (паравиртуализация): В последних версиях VirtualBox (6.0+) есть экспериментальная поддержка работы в режиме Hyper-V. В настройках виртуальной машины, в разделе «Система» → «Акцелерация», выберите «Hyper-V» вместо «VT-x/AMD-V». Это может снизить производительность, но позволит использовать обе технологии.
2. Переключение WSL2 на WSL1: Если виртуализация нужна только для WSL, можно вернуться к WSL1, который не использует гипервизор. Выполните в PowerShell:
wsl --set-default-version 1Это позволит отключить компонент Hyper-V, сохранив функциональность подсистемы Linux.
3. Временное отключение Sandbox: Для единичных случаев использования Sandbox его можно не устанавливать как компонент, а запускать через отдельный скрипт, который временно активирует необходимые службы. Однако это менее удобно для регулярного использования.
Причина 2: Блокировка средствами безопасности ОС и антивирусами
Функции безопасности, такие как «Изоляция ядра» (Memory Integrity) в Windows или некоторые компоненты антивирусов, могут намеренно блокировать доступ к аппаратной виртуализации для предотвращения атак, использующих уязвимости гипервизоров (например, так называемые «hypervisor cracks» для игр).
Отключение изоляции ядра и VBS в Windows Security
1. Откройте «Параметры Windows» → «Обновление и безопасность» → «Безопасность Windows» → «Безопасность устройства».
2. Найдите раздел «Изоляция ядра» и откройте «Сведения об изоляции ядра».
3. Отключите параметр «Целостность памяти» (Memory Integrity). Система потребует перезагрузки.
Эта функция использует Virtualization-based Security (VBS), которая, как и Hyper-V, требует монопольного доступа к VT-x/AMD-V.
Настройки антивирусов: Касперский, ESET, Avast
В современных антивирусах функции аппаратного ускорения или защиты от эксплойтов также могут конфликтовать с виртуализацией.
• В Kaspersky: Откройте главное окно → «Дополнительные инструменты» → «Антивирус» → «Полная проверка». Найдите настройки, связанные с «Аппаратное ускорение» или «Виртуализация для анализа угроз», и временно отключите их для диагностики.
• В ESET: Перейдите в «Настройки» → «Защита от эксплойтов» (или «HIPS») и проверьте параметры, использующие технологию виртуализации.
• В Avast/AVG: В «Настройках» → «Компоненты» часто есть раздел «Аппаратное ускорение» в модуле «Поведение защиты».
После отключения перезагрузите компьютер и проверьте работу гипервизора. Если проблема устранена, можно попробовать найти более тонкую настройку, которая не требует полного отключения защиты.
Причина 3: Устаревший микрокод процессора и настройки прошивки
Микрокод процессора — это набор инструкций, который управляет его низкоуровневыми функциями, включая виртуализацию. Устаревший микрокод может содержать ошибки, которые приводят к некорректной работе VT-x/AMD-V, даже если поддержка включена в BIOS.
Обновление микрокода:
1. Через обновление BIOS/UEFI: Самый надежный способ. Загрузите последнюю стабильную версию прошивки с сайта производителя материнской платы и установите её.
2. В Linux: Микрокод обновляется через пакеты intel-microcode (для Intel) или amd64-microcode (для AMD). Установка обычно происходит автоматически, но можно проверить и установить явно:sudo apt-get install intel-microcode
После установки требуется перезагрузка.
3. В Windows: Обновления микрокода часто распространяются через обновления Windows или драйверы чипсета от производителя (Intel Driver & Support Assistant, AMD Chipset Driver). Проверьте их наличие и установьте.
Быстрая загрузка (Fast Boot): Эта функция в BIOS/UEFI и Windows может «заморозить» некоторые настройки, включая состояние виртуализации, между сеансами. Попробуйте отключить Fast Boot:
• В BIOS/UEFI: Найдите параметр «Fast Boot» и установите «Disabled».
• В Windows: В «Параметрах электропитания» отключите «Включить быстрый запуск».
Режим загрузки (Legacy/CSM vs. UEFI): Загрузка в Legacy (CSM) режиме иногда вызывает проблемы с доступом к современным функциям процессора. Убедитесь, что система загружается в чистом режиме UEFI, а CSM (Compatibility Support Module) отключен.
Решение для конкретных гипервизоров: VMware, VirtualBox, KVM
После устранения системных конфликтов проверьте настройки конкретного программного обеспечения.
VMware Workstation/Player: Если возникает ошибка «VT-x is disabled», помимо системных проверок:
1. Убедитесь, что в настройках виртуальной машины (VM Settings → Processors) выбрано «Virtualize Intel VT-x/EPT or AMD-V/RVI».
2. Попробуйте использовать утилиту vmware-config.pl (в Linux) для повторной конфигурации гипервизора.
3. Проверьте, не запущены ли другие виртуальные машины или службы VMware, которые могли захватить ресурсы.
VirtualBox: При ошибке «VT-x is not available»:
1. В настройках виртуальной машины (System → Acceleration) убедитесь, что выбрана «Hardware Virtualization» и включены «Enable VT-x/AMD-V» и «Enable Nested Paging».
2. Попробуйте переключить режим акцелерации на «Hyper-V» (как описано выше), если он доступен.
3. Проверьте, не установлен ли параллельно Hyper-V или VMware, даже если они не активны.
KVM/QEMU в Linux: Ошибки от libvirt часто связаны с правами доступа:
1. Проверьте наличие устройства /dev/kvm: ls -l /dev/kvm. Если оно существует, убедитесь, что ваш пользователь имеет права на чтение/запись.
2. Добавьте пользователя в группу kvm: sudo usermod -a -G kvm $USER.
3. После этого перезапустите службу libvirt: sudo systemctl restart libvirtd.
Дополнительные сценарии и заключительные проверки
Виртуализация в нишевых системах: Для систем типа TrueNAS Core/Scale или Proxmox VE убедитесь, что виртуализация включена не только для основной системы, но и в настройках самого гипервизора (например, в Proxmox нужно проверить параметры узла).
Эмуляторы на ПК (MEmu Play, BlueStacks): Эти эмуляторы также используют VT-x/AMD-V для повышения производительности. Все рекомендации по отключению Hyper-V и функций безопасности Windows применимы к ним в равной степени.
Итоговый чек-лист:
1. Проверка: Выполните диагностические команды для своей ОС (Windows или Linux).
2. Отключение Hyper-V и безопасности: Если обнаружены активные компоненты, отключите их через графический интерфейс или PowerShell и перезагрузитесь.
3. Настройка антивируса: Временно отключите функции аппаратного ускорения или защиты от эксплойтов.
4. Обновление BIOS/микрокода: Установите последнюю версию прошивки и микрокода процессора.
5. Проверка гипервизора: Убедитесь в правильных настройках конкретного ПО (VMware, VirtualBox, KVM).
Когда всё остальное не помогает: Проверьте логи гипервизора (например, в VMware Workstation это файлы в директории виртуальной машины) на наличие специфичных ошибок. Поищите решение по точному тексту ошибки в официальной документации или сообществах, таких как форумы разработчиков.
Для глубокого понимания принципов виртуализации и контейнеризации, которые часто используются вместе, рекомендуем ознакомиться с полным практическим руководством по Docker для системных администраторов и DevOps. В нем разбираются основы архитектуры, отличия от виртуальных машин и готовые примеры развертывания.