Аппаратная виртуализация процессора: что это, как проверить и включить

Аппаратная виртуализация — базовая функция современных x86-64 платформ Intel и AMD. Без неё не работают многие привычные инструменты: Hyper-V, WSL2, Docker Desktop, Windows Sandbox, VMware Workstation, VirtualBox и серверные гипервизоры. Для рабочей станции разработчика это вопрос удобства. Для корпоративной инфраструктуры — вопрос плотности виртуальных машин, изоляции нагрузок и управляемости ресурсов.

Мы в Work System регулярно подбираем серверные платформы под кластеры виртуализации, 1С, СУБД и инфраструктурные сервисы. На практике проблема часто не в отсутствии поддержки аппаратной виртуализации процессора, а в том, что VT-x или AMD-V отключены в BIOS/UEFI, заняты Hyper-V/VBS или не видны операционной системе из-за устаревшей прошивки.

Если нужен быстрый ответ — вот план действий. Занимает 5–10 минут:

1. Откройте Диспетчер задач (Ctrl + Shift + Esc) → «Производительность» → «ЦП» → проверьте строку «Виртуализация».
2. Если статус «Отключено» — перезагрузите ПК или сервер и войдите в BIOS/UEFI (клавиши Del, F2, F10, F12 при старте).
3. Для Intel: включите Intel Virtualization Technology / VT-x / VMX.
4. Для AMD: включите SVM Mode / AMD-V / Secure Virtual Machine.
5. Сохраните настройки через Save & Exit и загрузите Windows.
6. Проверьте результат командой systeminfo или через PowerShell.
7. Если нужны Hyper-V, WSL2, Docker Desktop или Windows Sandbox — включите соответствующие компоненты Windows через «Включение или отключение компонентов Windows».
8. Если нужны VMware Workstation или VirtualBox и появляется ошибка «VT-x/AMD-V is not available» — проверьте конфликт с Hyper-V, VBS и HVCI (подробности ниже).

Дальше — детальное объяснение каждого шага, архитектура технологии виртуализации, серверные сценарии и диагностика типичных проблем.

Аппаратная виртуализация процессора — это технология, при которой CPU предоставляет гипервизору специальные режимы и инструкции для запуска гостевых ОС почти напрямую на физическом процессоре. В отличие от программной виртуализации и эмуляции, большинство инструкций гостевой системы выполняется самим CPU, а гипервизор вмешивается только при чувствительных операциях — так называемых привилегированных вызовах.

Если коротко отвечать на вопрос «аппаратная виртуализация — что это такое», речь идёт не о «программе для виртуальных машин», а о наборе аппаратных расширений процессора и платформы. Они позволяют гипервизору управлять виртуальными CPU, памятью, прерываниями и доступом к устройствам на аппаратном уровне.

По данным Intel® 64 and IA-32 Architectures Software Developer's Manual от Intel, 2025, VMX разделяет выполнение на root и non-root режимы. В root-режиме работает гипервизор, в non-root — гостевая ОС. Гость может считать, что управляет процессором напрямую, но критичные события вызывают VM-exit и передаются гипервизору. Именно этот механизм и отличает аппаратную виртуализацию от чисто программных подходов.

По данным AMD64 Architecture Programmer's Manual от AMD, 2025, SVM использует VMCB (Virtual Machine Control Block) для хранения состояния виртуального процессора и перехватов. Гостевая ОС запускается через специальные инструкции, а состояние виртуальной машины хранится в управляющих структурах памяти.

Ключевое отличие от программной виртуализации — отсутствие постоянной двоичной трансляции инструкций. При программной эмуляции гипервизор или эмулятор переводит команды гостевой архитектуры в команды хоста. Это даёт кратно больший overhead. По NIST SP 800-125 от NIST, 2011, аппаратная поддержка CPU и MMU помогает гипервизорам снижать накладные расходы виртуализации. На практике программная эмуляция x86 через QEMU/TCG в CPU-bound сценариях работает заметно медленнее из-за dynamic binary translation, тогда как при аппаратной виртуализации накладные расходы для типовых серверных нагрузок измеряются единицами процентов.

У Intel аппаратная виртуализация называется Intel Virtualization Technology, а ключевой механизм CPU — VT-x. У AMD аналогичная технология называется AMD-V или SVM Mode. Эти названия важно знать при проверке поддержки виртуализации и настройке BIOS/UEFI — путаница в терминах встречается на удивление часто.

По Intel® 64 and IA-32 Architectures Software Developer's Manual от Intel, 2025, VMX включает инструкции VMXON, VMXOFF, VMLAUNCH, VMRESUME, VMREAD, VMWRITE, VMCLEAR, VMPTRLD, INVEPT и INVVPID. Они используются гипервизором для запуска, остановки и управления виртуальными машинами на уровне CPU.

У Intel есть несколько связанных, но разных технологий:

По Intel Virtualization Technology for Directed I/O Architecture Specification от Intel, 2024, VT-d обеспечивает DMA-remapping и remapping прерываний для устройств. Поэтому включение Intel VT-x и Intel VT-d — не одно и то же. VT-x отвечает за запуск гостевой ОС на CPU, а VT-d — за изоляцию и перенаправление операций ввода-вывода через IOMMU. Типичная ошибка — включить только VT-x и удивляться, почему passthrough GPU или NVMe-диска в виртуальную машину не работает.

У AMD картина похожая:

По AMD64 Architecture Programmer's Manual от AMD, 2025, SVM использует собственные структуры состояния виртуальной машины и инструкции, включая VMRUN, VMSAVE и VMLOAD. Для пользователя это обычно скрыто за пунктом BIOS/UEFI «SVM Mode» или «Secure Virtual Machine».

Аппаратную поддержку виртуализации нужно использовать для запуска виртуальных машин, WSL2, Docker Desktop, Windows Sandbox, эмуляторов мобильных ОС и функций безопасности Windows на базе гипервизора. Если виртуализация отключена, эти компоненты могут не запуститься или будут работать нестабильно. Вот, собственно, главная причина, по которой стоит разобраться с этой настройкой.

Основные сценарии:

По Microsoft Learn «System requirements for Hyper-V on Windows» от Microsoft, 2025, Hyper-V требует x64-процессор со SLAT и включённую виртуализацию в процессоре. Минимальный объём RAM — 4 ГБ. Hyper-V поддерживается в редакциях Windows Pro, Enterprise и Education. В Windows Home роль Hyper-V для управления виртуальными машинами недоступна, однако компонент Virtual Machine Platform, необходимый для WSL2 и Docker Desktop, может использоваться и в Home-редакции — это отдельный сценарий, о котором часто забывают.

По WSL FAQ от Microsoft, 2025, WSL2 использует виртуализацию для запуска Linux-ядра и дистрибутивов. Docker Desktop на Windows также опирается на WSL2 или Hyper-V как базовый механизм запуска Linux-контейнеров. При ошибке запуска Docker Desktop проверьте, включён ли компонент Virtual Machine Platform и работает ли WSL2 командой wsl --status.

По Windows Sandbox от Microsoft, 2025, песочница использует аппаратную виртуализацию для изоляции ядра через Microsoft Hypervisor. Windows Sandbox доступна в редакциях Pro и Enterprise, но не в Home.

Для серверных гипервизоров требования аналогичны: 64-битный x86 CPU с аппаратной поддержкой виртуализации и SLAT. Но есть нюанс. Минимальные системные требования — это именно минимальная планка, а не рекомендация под продуктивную нагрузку. Для кластера на 50–100 ВМ разница между «минимум» и «рекомендация» может составлять порядок по RAM и количеству ядер.

Отдельно стоит учитывать безопасность. По документации Credential Guard от Microsoft, 2025, технология использует аппаратную виртуализацию для изоляции учётных данных NTLM и Kerberos. VBS создаёт изолированную виртуальную среду через Windows Hypervisor, а HVCI обеспечивает проверку целостности кода ядра. Для HVCI требуются x64 CPU, SLAT и включённые Intel VT-x или AMD-V.

Из практики Work System: в проекте для промышленно-продовольственного кластера «Косино» наша команда помогала построить кластер виртуализации и хранения данных с требованиями к снэпшотам, репликации, дедупликации, кластеризации и LUN. В таких проектах аппаратную поддержку виртуализации мы проверяем ещё на этапе подбора серверов, потому что от неё зависят совместимость гипервизора, сценарии отказоустойчивости и дальнейшее масштабирование.

Проверить поддержку аппаратной виртуализации можно без входа в BIOS/UEFI: через Диспетчер задач Windows, systeminfo, msinfo32, WMI/CIM и утилиты производителя. Эти методы показывают, поддерживает ли CPU нужные расширения и включена ли виртуализация на устройстве в микропрограмме.

По Microsoft Learn по Hyper-V от Microsoft, 2025, готовность проверяют по VM Monitor Mode Extensions, Virtualization Enabled in Firmware и SLAT. Для Hyper-V и WSL2 особенно важны виртуализация в прошивке и SLAT: без SLAT (EPT у Intel, NPT у AMD) Hyper-V и WSL2 не запустятся даже при наличии базовой виртуализации CPU.

Перед изменением BIOS мы рекомендуем сделать три проверки:

1. Посмотреть статус в Диспетчере задач.
2. Выполнить systeminfo.
3. При спорном результате — проверить модель CPU в документации Intel или AMD.

Если в Windows указано, что аппаратная виртуализация отключена, это не всегда означает отсутствие поддержки. Часто функция просто выключена в BIOS/UEFI или занята другим гипервизором.

В Windows 10 и Windows 11 статус виртуализации проще всего проверить в Диспетчере задач. Если строка «Виртуализация» показывает «Включено» — аппаратная виртуализация включена и доступна операционной системе.

Алгоритм:

1. Нажмите Ctrl + Shift + Esc (или Ctrl + Alt + Del → «Диспетчер задач»).
2. Откройте вкладку «Производительность».
3. Выберите раздел «ЦП».
4. Найдите строку «Виртуализация».
5. Проверьте статус: «Включено» или «Отключено».

По Microsoft Support «Enable virtualization on Windows» от Microsoft, 2025, статус виртуализации проверяют на вкладке «Производительность» → «ЦП». Включённая виртуализация в микропрограмме должна быть видна ОС до установки роли Hyper-V.

Интерпретация результатов:

Команда systeminfo показывает более детальную картину, чем Диспетчер задач. Она полезна, когда нужно проверить не только статус включения, но и поддержку SLAT и требований Hyper-V на компьютере.

Откройте CMD или PowerShell от имени администратора и выполните:

systeminfo

В нижней части вывода найдите блок требований Hyper-V. На английской системе он выглядит примерно так:

В русской локализации Windows смысл тот же: строка «Обнаружена виртуализация в микропрограмме» соответствует Virtualization Enabled In Firmware. Значение Yes означает, что аппаратная виртуализация включена в BIOS/UEFI. Значение No — нужно проверить настройки прошивки.

По Microsoft Learn по systeminfo от Microsoft, 2025, блок Hyper-V Requirements показывает виртуализацию в прошивке и поддержку SLAT. Если Second Level Address Translation имеет значение No, Hyper-V и WSL2 могут не запуститься даже при наличии базовой виртуализации CPU.

Дополнительная проверка через PowerShell:

Дополнительно можно проверить поддержку CPU фирменными утилитами:

• Intel: Intel Processor Identification Utility → раздел CPU Technologies. Проверьте наличие строки Intel Virtualization Technology.
• AMD: проверяйте поддержку AMD-V/SVM по модели процессора на странице спецификаций AMD или через актуальную утилиту производителя, если она доступна для вашей платформы.

Важно: наличие поддержки в CPU не означает, что виртуализация уже включена. Если BIOS/UEFI блокирует VT-x или SVM, Windows покажет виртуализацию как отключённую.

Для серверных сценариев с KVM, Proxmox VE или другими Linux-гипервизорами проверка выполняется из терминала:

egrep -c '(vmx|svm)' /proc/cpuinfo

Если результат больше 0, процессор поддерживает аппаратную виртуализацию. Дополнительные проверки:

lscpu | grep Virtualization — информация о типе виртуализации в процессоре.

lsmod | grep kvm — проверка загруженных модулей KVM.

virt-host-validate — комплексная валидация хоста для систем виртуализации.

dmesg | grep -i -e iommu -e dmar и find /sys/kernel/iommu_groups/ -type l — проверка поддержки IOMMU.

Для включения IOMMU на Linux-хосте добавьте параметр в конфигурацию загрузчика GRUB: intel_iommu=on для Intel или amd_iommu=on для AMD. Проверка nested virtualization:

cat /sys/module/kvm_intel/parameters/nested — для Intel.
cat /sys/module/kvm_amd/parameters/nested — для AMD.

Практический вывод: systeminfo — основной способ понять, готов ли Windows-компьютер к Hyper-V, WSL2 и Docker Desktop. Для Linux/KVM используйте lscpu, /proc/cpuinfo и virt-host-validate. Если один из ключевых признаков отсутствует, включение компонентов ОС проблему не решит — нужно разбираться с BIOS/UEFI или, в крайнем случае, менять платформу.

Включить аппаратную виртуализацию нужно именно в BIOS/UEFI, потому что ОС не может активировать VT-x или AMD-V, если прошивка платформы запретила доступ к этим расширениям. По Microsoft Support «Enable virtualization on Windows» от Microsoft, 2025, параметры виртуализации обычно ищут в разделах Advanced, CPU Configuration, System Configuration или Security.

Типовой порядок настройки виртуализации:

1. Перезагрузите компьютер или сервер.
2. Войдите в BIOS/UEFI клавишей Del, F2, F10, F12 или Esc — точная клавиша зависит от производителя.
3. Перейдите в расширенный режим, если UEFI открылся в упрощённом интерфейсе.
4. Найдите раздел CPU Configuration, Advanced CPU Settings, CPU Features или аналогичный.
5. Включите параметр виртуализации.
6. Сохраните настройки через F10 или пункт Save Changes and Reset.
7. После загрузки Windows проверьте статус через Диспетчер задач или systeminfo.

Вход в UEFI из Windows различается по версиям:

• Windows 11: «Параметры» → «Система» → «Восстановление» → «Особые варианты загрузки» → «Перезагрузить сейчас» → «Диагностика» → «Дополнительные параметры» → «Параметры встроенного ПО UEFI».
• Windows 10: «Параметры» → «Обновление и безопасность» → «Восстановление» → «Особые варианты загрузки» → «Перезагрузить сейчас» → далее как выше.

Если пункта «Параметры встроенного ПО UEFI» нет, система может быть загружена не в UEFI-режиме (Legacy BIOS). В этом случае входите по горячей клавише при старте (Del, F2, F10, F12) и проверьте документацию материнской платы или сервера.

Обратите внимание: после обновления BIOS/UEFI или сброса CMOS параметры могут вернуться к значениям по умолчанию. Мы рекомендуем фиксировать настройки BIOS-профиля в эксплуатационной документации, особенно для серверов в кластере. В нашей практике были случаи, когда после замены батарейки CMOS на одном узле кластера виртуализация «слетала», и live migration переставал работать.

Для серверов Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem и Supermicro параметры виртуализации обычно находятся в разделах Processor Settings или System Security. Вход может выполняться не только с физической консоли, но и через интерфейсы удалённого управления: iDRAC (Dell), iLO (HPE), XClarity/IMM (Lenovo), IPMI/BMC (Supermicro). Для серверов отечественных производителей сверяйтесь с документацией конкретной модели и версией прошивки.

Практический вывод: не меняйте соседние параметры CPU без необходимости. Для включения аппаратной виртуализации достаточно активировать VT-x/SVM, а VT-d/IOMMU включать только при сценариях passthrough, SR-IOV или повышенных требованиях к I/O-изоляции.

Для Intel нужно включить параметр Intel Virtualization Technology, Intel VT-x или Intel VMX. Если требуется проброс устройств в виртуальные машины, дополнительно включают Intel VT-d.

Типовые названия в BIOS/UEFI:

По Intel® 64 and IA-32 Architectures Software Developer's Manual от Intel, 2025, VMX включается на уровне процессора и управляется гипервизором через специальные VMX-инструкции. По Intel «Does My Processor Support Intel Virtualization Technology?» от Intel, 2025, доступность VT-x зависит от поддержки CPU и настроек BIOS/UEFI: даже если процессор поддерживает виртуализацию, прошивка платформы может её блокировать.

По Intel Virtualization Technology for Directed I/O Architecture Specification от Intel, 2024, VT-d связывает PCIe-устройства с отдельными таблицами трансляции. Поэтому VT-d важен для серверов с PCI passthrough, сетевыми картами SR-IOV, NVMe passthrough или GPU-виртуализацией, но не обязателен для простого запуска обычных ВМ. Например, на Dell PowerEdge R760 или HPE ProLiant DL380 Gen11 оба параметра — VT-x и VT-d — доступны в разделе Processor Settings и включаются независимо друг от друга.

Практический вывод: если цель — Hyper-V, VirtualBox, VMware Workstation или WSL2, сначала включите Intel VT-x. Если планируется корпоративный гипервизор с пробросом устройств, включите также VT-d и проверьте совместимость платформы виртуализации.

Для AMD нужно включить SVM Mode, AMD-V или Secure Virtual Machine. Для проброса устройств и аппаратной изоляции ввода-вывода дополнительно включают IOMMU.

Типовые названия в BIOS/UEFI:

По AMD Secure Virtual Machine Architecture Reference Manual от AMD, 2025, NPT выполняет двухуровневую трансляцию гостевых адресов. Это снижает накладные расходы при работе гостевой памяти по сравнению с shadow paging — разница особенно заметна при большом количестве ВМ с активным обменом данными.

У разных производителей плат пункт может находиться в разных разделах: Advanced, CPU Configuration, OC, CPU Features или CBS. Это нормальная ситуация. Важно искать именно SVM Mode или Secure Virtual Machine, а не общий пункт «Virtualization», которого на некоторых AMD-платформах попросту нет.

После включения виртуализации в BIOS/UEFI нужно активировать нужные компоненты Windows. Для виртуальных машин и связанных функций обычно используются Hyper-V, «Платформа виртуальной машины», Windows Hypervisor Platform и «Песочница Windows».

По Microsoft Learn «System requirements for Hyper-V on Windows» от Microsoft, 2025, Hyper-V поддерживается в Pro, Enterprise и Education. Требуется 64-bit processor с SLAT и минимум 4 ГБ RAM.

Порядок включения виртуализации в Windows через графический интерфейс:

1. Откройте «Панель управления».
2. Перейдите в «Программы».
3. Откройте «Включение или отключение компонентов Windows».
4. Отметьте нужные компоненты.
5. Нажмите OK.
6. Перезагрузите систему.

Что включать:

По WSL FAQ от Microsoft, 2025, WSL2 использует виртуализированное Linux-ядро и компонент Virtual Machine Platform. Docker Desktop на Windows также использует WSL2 или Hyper-V как базовый механизм запуска Linux-контейнеров.

Команда PowerShell для включения Hyper-V на поддерживаемых редакциях Windows:

После выполнения потребуется перезагрузка.

Один из самых частых вопросов — что включать, а что отключать. Вот таблица для быстрого выбора:

Современные версии VMware Workstation и VirtualBox могут работать через Windows Hypervisor Platform при включённом Hyper-V, но с определёнными ограничениями производительности. Если активен Windows Hypervisor, сторонние гипервизоры либо работают через Windows Hypervisor Platform, либо требуют отключения Hyper-V/VBS. Для оптимальной производительности VMware/VirtualBox без компромиссов рекомендуется отключать Hyper-V, VMP, WHP и HVCI.

Если аппаратная виртуализация отключена или не работает, причина обычно находится в одном из четырёх мест: BIOS/UEFI, старый CPU или чипсет, конфликт гипервизоров, функции безопасности Windows. Реже мешают быстрый запуск Windows, сторонние антивирусы и устаревшая прошивка. Давайте разберём по порядку.

Типовые причины и решения:

По Intel «Does My Processor Support Intel Virtualization Technology?» от Intel, 2025, поддержку VT-x проверяют по спецификации CPU или Intel Processor Identification Utility. Старые платформы без VT-x, AMD-V, EPT или NPT не поддерживают современные гипервизоры, и решение в этом случае — замена аппаратной платформы, а не настройка Windows.

Отдельный частый конфликт — одновременное использование Hyper-V, VBS, HVCI, VMware Workstation и VirtualBox. По документации Credential Guard от Microsoft, 2025, VBS использует гипервизор для изоляции защищённых сред и учётных данных. Когда Windows Hypervisor уже активен, сторонний гипервизор может не получить прямой доступ к VT-x/AMD-V и должен работать через Windows Hypervisor Platform либо требовать отключения Hyper-V/VBS.

Некоторые антивирусные продукты уровня Internet Security включают защиту на базе гипервизора или используют драйверы, связанные с HVCI. Конфликт устраняется не отключением всей защиты, а точечной деактивацией модуля virtualization protection или hypervisor protection с последующей перезагрузкой.

Рекомендуемый порядок диагностики:

1. Проверить статус в Диспетчере задач.
2. Выполнить systeminfo.
3. Проверить, включён ли Hyper-V: bcdedit /enum {current}
4. Посмотреть параметр hypervisorlaunchtype. Команда bcdedit требует прав администратора.
5. Если нужно включить гипервизор Windows: bcdedit /set hypervisorlaunchtype auto
6. Если нужно временно отключить гипервизор Windows для совместимости со сторонним гипервизором: bcdedit /set hypervisorlaunchtype off
7. Перезагрузить компьютер.
8. При сохранении проблемы — выполнить полное выключение, а не обычную перезагрузку. Быстрый запуск Windows иногда «кэширует» старое состояние.

Дополнительные способы проверки VBS/HVCI: через msinfo32 → «Безопасность на основе виртуализации»; через PowerShell/CIM; через «Безопасность Windows» → «Безопасность устройства» → «Изоляция ядра» → «Целостность памяти».

Материал носит информационный характер и не заменяет официальных требований регуляторов и консультации профильного специалиста.

Из практики Work System: при подборе серверов под отказоустойчивые кластеры 1С и СУБД мы проверяем не только количество ядер и объём RAM, но и поддержку SLAT, IOMMU, совместимость CPU в пределах кластера и доступность нужных настроек BIOS/UEFI. В проекте для КазКонтракт Трейд наша команда за месяц создала вычислительный кластер на базе оборудования Dell — для подобных задач предсказуемая работа гипервизора и аппаратной виртуализации критична не меньше, чем номинальная производительность CPU.

В корпоративной инфраструктуре аппаратная виртуализация связана не только с запуском ВМ, но и с защитой данных. VBS, HVCI и Credential Guard опираются на Windows Hypervisor и требуют VT-x/AMD-V с поддержкой SLAT. Отключение этих функций ради совместимости с VMware или VirtualBox может нарушить требования информационной безопасности. Стоит ли оно того? Зависит от конкретной политики ИБ, но решение точно не должно приниматься «на лету».

IOMMU (Intel VT-d / AMD-Vi) обеспечивает защиту от DMA-атак и изоляцию устройств: каждое PCIe-устройство получает собственную таблицу трансляции адресов и не может обращаться к памяти, принадлежащей другим устройствам или ОС. Это критично для серверов с PCI passthrough и для защиты от физических атак через Thunderbolt/FireWire.

Практические правила:

• На рабочих станциях с корпоративной политикой ИБ не отключайте VBS/HVCI без согласования с администратором безопасности.
• На серверах проверяйте совместимость гипервизора и политик защиты до развёртывания.
• Если инфраструктура обрабатывает персональные данные (152-ФЗ), относится к объектам КИИ (187-ФЗ) или использует сертифицированные ОС и средства защиты (требования ФСТЭК), изменение настроек виртуализации и безопасности должно проходить через установленные процедуры согласования.

Для серверной виртуализации важно не просто наличие VT-x/AMD-V, а полная совместимость платформы с выбранным гипервизором. Ниже — сводная таблица ключевых требований.

При планировании кластеров важна совместимость CPU в рамках одного пула: смешивание разных поколений процессоров (например, Intel 3-го и 5-го поколений Xeon Scalable) ограничивает live migration. VMware решает это через EVC (Enhanced vMotion Compatibility), Microsoft — через Processor Compatibility Mode. В обоих случаях набор функций CPU выравнивается до минимального общего знаменателя, что может ограничить доступные инструкции и, как следствие, производительность отдельных нагрузок.

Из опыта наших инженеров: при проектировании кластеров виртуализации мы всегда проверяем единый stepping и поколение CPU на всех узлах, совместимость платформы с HCL выбранного гипервизора и доступность IOMMU/SR-IOV в BIOS/UEFI. Это предотвращает проблемы на этапе эксплуатации, когда добавление нового узла с другим процессором блокирует vMotion или live migration. Для кластера из 4–8 узлов на Lenovo ThinkSystem SR650 V3 или Dell PowerEdge R760 мы рекомендуем заказывать все серверы одной партией — так проще гарантировать идентичный stepping.

Этот чек-лист мы используем в проектах Work System при подборе оборудования для кластеров виртуализации, 1С, СУБД и VDI.

При закупке по 44-ФЗ/223-ФЗ формулируйте требования к CPU без привязки к одному бренду: «64-разрядный процессор архитектуры x86-64 с поддержкой аппаратной виртуализации и SLAT, не менее N ядер, тактовая частота не менее M ГГц». Указывайте требования к IOMMU, SR-IOV и совместимости с конкретным гипервизором.

При импортозамещении обращайте внимание на: доступность документации и прошивок для российских серверных платформ, совместимость с отечественными ОС (Astra Linux, РЕД ОС, Альт) и платформами виртуализации, сроки поставки и сервисную поддержку.

После включения виртуализации в BIOS/UEFI и настройки компонентов ОС выполните финальные проверки:

1. Диспетчер задач: «Производительность» → «ЦП» → строка «Виртуализация: Включено».
2. systeminfo: все строки блока Hyper-V Requirements показывают Yes.
3. VirtualBox: при создании новой ВМ в списке появились 64-битные гостевые ОС (например, Ubuntu 64-bit).
4. VMware Workstation/Player: запуск 64-битной гостевой ОС проходит без предупреждений «VT-x/AMD-V is not available».
5. WSL2: команда wsl --status показывает WSL2 как версию по умолчанию.
6. Linux/KVM: lscpu | grep Virtualization показывает VT-x или AMD-V, lsmod | grep kvm показывает загруженные модули.

Если хотя бы один пункт не проходит — возвращайтесь к диагностике по цепочке CPU → BIOS → ОС → конфликтующее ПО.