После массового включения технологий виртуализации Intel VT-x или AMD-V в BIOS/UEFI серверов Gigabyte перед администратором встает рутинная задача: проверить корректность настройки на каждом хосте. Ручной обход десятков или сотен машин по SSH с выполнением команд kvm-ok и проверкой модулей ядра отнимает часы рабочего времени и чреват человеческими ошибками. Автоматизация этого процесса с помощью готовых скриптов и Ansible сокращает время проверки с часов до минут, гарантирует единообразие результатов и генерирует структурированный отчет для всего парка оборудования. Это решение исключает риск пропустить сервер с некорректными настройками, что критично для стабильной работы гипервизоров KVM, VMware ESXi или контейнерных сред Docker.
В этом руководстве представлены проверенные на практике методы: от быстрой проверки одного сервера через SSH до полной автоматизации аудита с помощью Ansible Playbook. Вы получите готовые команды для установки утилит cpu-checker и libvirt-tools, скрипт для интерпретации вывода kvm-ok и конфигурацию для массового сбора данных. Решение масштабируется на любое количество узлов и может быть интегрировано в CI/CD пайплайн обновления инфраструктуры, становясь обязательным этапом после прошивки BIOS.
Проблема: ручная проверка виртуализации на десятках серверов неэффективна
Типичный сценарий после настройки BIOS на парке серверов Gigabyte выглядит так: администратор подключается по SSH к первому хосту, устанавливает пакеты cpu-checker и libvirt-clients, выполняет sudo kvm-ok, анализирует вывод, проверяет загрузку модуля ядра kvm командой lsmod | grep kvm, затем повторяет эти шаги для второго, третьего, N-го сервера. Для 50 машин такая процедура занимает не менее двух часов чистого времени, без учета возможных сетевых задержек или необходимости переключения контекста.
Ручной подход создает три ключевых риска:
- Ошибки пропуска: уставший специалист может пропустить один из шагов проверки или неверно интерпретировать вывод команды.
- Отсутствие документации: результаты проверки остаются в терминальной истории или временных заметках, что затрудняет аудит и отчетность.
- Невозможность масштабирования: с ростом парка серверов время проверки растет линейно, отвлекая ресурсы от более важных задач.
Автоматизация с помощью скриптов и инструментов управления конфигурацией, таких как Ansible, устраняет эти недостатки. Единоразовая настройка playbook позволяет выполнить проверку на всех целевых хостах параллельно, собрать результаты в структурированный JSON или CSV отчет и интегрировать проверку в процесс непрерывного развертывания. Это соответствует принципам инфраструктуры как кода (IaC) и DevOps-практикам, которые подробно рассмотрены в нашем руководстве по автоматизации инфраструктуры.
Быстрая проверка на одном сервере Gigabyte через SSH
Для оперативной проверки состояния виртуализации на отдельном сервере Gigabyte после изменения настроек BIOS достаточно выполнить несколько команд в SSH-сессии. Этот метод подходит для точечного аудита или проверки перед развертыванием автоматизации.
Установка утилит cpu-checker и libvirt-tools
Перед запуском проверки необходимо установить диагностические пакеты. Команды зависят от дистрибутива Linux. Для систем на базе Debian/Ubuntu (включая Proxmox VE) выполните:
sudo apt update
sudo apt install cpu-checker libvirt-clients -yПакет cpu-checker содержит утилиту kvm-ok, которая проверяет поддержку аппаратной виртуализации процессором и корректность настроек BIOS. Пакет libvirt-clients предоставляет клиентские инструменты для работы с libvirt, а также включает полезные скрипты проверки.
Для систем на базе RHEL, CentOS, Rocky Linux или AlmaLinux используйте менеджер пакетов yum или dnf:
sudo yum install libvirt-client virt-what -y
# или
sudo dnf install libvirt-client virt-what -yУтилита virt-what выполняет схожую с kvm-ok диагностику и часто предустановлена в серверных дистрибутивах.
Запуск kvm-ok и интерпретация результатов
После установки пакетов выполните проверку:
sudo kvm-okУспешный вывод указывает на полную готовность системы к работе с KVM:
INFO: /dev/kvm exists
KVM acceleration can be usedЭто означает, что технология виртуализации (VT-x для Intel или AMD-V для AMD) включена в BIOS/UEFI, модуль ядра kvm загружен, и у пользователя есть права на доступ к устройству /dev/kvm.
Типичные ошибки и их значение:
- "Your CPU does not support KVM extensions": процессор физически не поддерживает аппаратную виртуализацию либо она отключена в BIOS. Необходимо войти в интерфейс UEFI сервера Gigabyte и активировать опцию "Intel Virtualization Technology", "Intel VT-x", "AMD SVM" или "AMD-V". Детальная инструкция по настройке BIOS доступна в статье "Как включить виртуализацию в BIOS Gigabyte".
- "INFO: /dev/kvm does not exist" при поддержке процессором KVM: модуль ядра
kvmне загружен. Загрузите его вручную:sudo modprobe kvm(для Intel) илиsudo modprobe kvm_amd(для AMD). Для автоматической загрузки при старте добавьте модуль в/etc/modules-load.d/. - "KVM acceleration can NOT be used" с сообщением о правах доступа: пользователь не входит в группу
kvm. Добавьте текущего пользователя:sudo usermod -aG kvm $USERи перезайдите в систему.
Дополнительно проверьте загрузку модулей ядра и флаги процессора:
lsmod | grep kvm
cat /proc/cpuinfo | grep -E "(vmx|svm)"Наличие строки vmx (Intel) или svm (AMD) в выводе /proc/cpuinfo подтверждает поддержку на уровне процессора. Для проверки возможности вложенной виртуализации (nested) выполните:
cat /sys/module/kvm_*/parameters/nestedЗначение Y или 1 указывает на активную поддержку.
Массовая автоматизация проверок с помощью Ansible
Ansible позволяет проверить поддержку виртуализации на всем парке серверов Gigabyte одной командой, собрать результаты в централизованный отчет и интегрировать проверку в рабочие процессы. Этот подход заменяет рутину управляемым кодом.
Подготовка инвентаря и управляющего узла Ansible
На управляющем узле (control node) должен быть установлен Ansible (версии 2.9 или выше) и Python 3. Убедитесь, что SSH-доступ по ключам настроен для всех целевых серверов. Создайте инвентарный файл inventory.ini:
[gigabyte_servers]
server-01.gigabyte.lan ansible_user=admin
server-02.gigabyte.lan ansible_user=admin
server-03.gigabyte.lan ansible_user=admin
[gigabyte_servers:vars]
ansible_python_interpreter=/usr/bin/python3Группа gigabyte_servers содержит список хостов. Переменная ansible_user задает пользователя для подключения. Для больших инфраструктур инвентарь можно генерировать динамически из CMDB или облачных провайдеров.
Ansible Playbook для сбора отчета о виртуализации
Создайте файл check_virt.yml со следующим содержимым. Этот playbook идемпотентен: его многократный запуск не изменит состояние систем, а только соберет актуальные данные.
---
- name: Проверка поддержки виртуализации на серверах Gigabyte
hosts: gigabyte_servers
become: yes
gather_facts: yes
tasks:
- name: Установка cpu-checker (Debian/Ubuntu)
apt:
name:
- cpu-checker
- libvirt-clients
state: present
update_cache: yes
when: ansible_os_family == "Debian"
- name: Установка libvirt-client (RHEL/CentOS)
yum:
name:
- libvirt-client
- virt-what
state: present
when: ansible_os_family == "RedHat"
- name: Выполнение проверки kvm-ok
command: kvm-ok
register: kvm_check_result
changed_when: false
ignore_errors: yes
- name: Проверка загрузки модуля KVM
shell: lsmod | grep -q kvm && echo "KVM module loaded" || echo "KVM module not loaded"
register: kvm_module_check
changed_when: false
- name: Проверка флагов процессора (vmx/svm)
shell: grep -E "(vmx|svm)" /proc/cpuinfo | head -1
register: cpu_flags_check
changed_when: false
- name: Сбор результатов в локальный отчет
local_action:
module: copy
content: |
{
"{{ inventory_hostname }}": {
"kvm_ok_output": "{{ kvm_check_result.stdout | default('N/A') }}",
"kvm_ok_failed": {{ kvm_check_result.failed | to_json }},
"kvm_module": "{{ kvm_module_check.stdout }}",
"cpu_flags": "{{ cpu_flags_check.stdout | default('N/A') }}",
"distribution": "{{ ansible_distribution }} {{ ansible_distribution_version }}",
"timestamp": "{{ ansible_date_time.iso8601 }}"
}
}
dest: "/tmp/{{ inventory_hostname }}_virt_check.json"
run_once: yes
delegate_to: localhost
post_tasks:
- name: Объединение отчетов в единый файл
local_action:
module: assemble
src: "/tmp/"
dest: "./report_virtualization_check.json"
regexp: ".*_virt_check\.json$"
run_once: yes
delegate_to: localhost
- name: Очистка временных файлов
local_action:
module: file
path: "/tmp/{{ inventory_hostname }}_virt_check.json"
state: absent
delegate_to: localhostPlaybook выполняет следующие задачи: определяет дистрибутив ОС, устанавливает необходимые пакеты, запускает проверку kvm-ok, проверяет загрузку модуля ядра и наличие флагов процессора. Результаты каждого хоста сохраняются в отдельный временный JSON-файл, а на этапе post_tasks объединяются в единый отчет report_virtualization_check.json на управляющем узле.
Запуск плейбука и анализ сводного отчета
Запустите проверку на всех серверах из инвентаря:
ansible-playbook -i inventory.ini check_virt.ymlПосле успешного выполнения в текущей директории появится файл report_virtualization_check.json. Его структура позволяет быстро идентифицировать проблемные узлы:
{
"server-01.gigabyte.lan": {
"kvm_ok_output": "INFO: /dev/kvm exists\nKVM acceleration can be used",
"kvm_ok_failed": false,
"kvm_module": "KVM module loaded",
"cpu_flags": "flags\t\t: ... vmx ...",
"distribution": "Ubuntu 22.04",
"timestamp": "2026-05-04T10:30:15Z"
},
"server-02.gigabyte.lan": {
"kvm_ok_output": "INFO: /dev/kvm does not exist\nKVM acceleration can NOT be used",
"kvm_ok_failed": true,
"kvm_module": "KVM module not loaded",
"cpu_flags": "flags\t\t: ... vmx ...",
"distribution": "CentOS 9",
"timestamp": "2026-05-04T10:30:17Z"
}
}Отчет можно интегрировать в системы мониторинга (Zabbix, Prometheus) или отправлять в корпоративные чаты (Telegram, Slack) через webhook. Для постоянного аудита добавьте запуск playbook в cron или системный таймер. Такой подход к автоматизации рутинных задач подробно описан в нашей базе знаний в статье об автоматизации администрирования Linux.
Интеграция в CI/CD пайплайн обновления серверов
Для DevOps-инженеров, управляющих инфраструктурой как кодом, проверка виртуализации становится естественным этапом пайплайна обновления. После автоматической прошивки BIOS серверов Gigabyte с помощью фирменных утилит (например, через gb-fwupd или IPMI) запускается Ansible Playbook для верификации настроек. Условный переход на этап развертывания гипервизора (KVM, Proxmox) происходит только при успешной проверке на всех хостах.
Пример сценария в GitLab CI/CD:
stages:
- bios_update
- virt_validation
- hypervisor_deploy
validate_virtualization:
stage: virt_validation
script:
- ansible-playbook -i inventory/production.ini playbooks/check_virt.yml
- python scripts/parse_report.py --require-all-success
artifacts:
paths:
- report_virtualization_check.json
only:
- masterСкрипт parse_report.py анализирует JSON-отчет и возвращает код ошибки, если хотя бы на одном сервере проверка не пройдена. Это предотвращает развертывание виртуальных машин на неподготовленной инфраструктуре. Подобная практика исключает "поломку" на уровне гипервизора после массовых обновлений и соответствует принципам непрерывной интеграции и доставки. Для комплексной автоматизации процессов развертывания и контроля можно использовать агрегатор API AiTunnel, который предоставляет единый интерфейс для интеграции различных сервисов и моделей.
Устранение проблем: если проверка kvm-ok не прошла
Когда автоматизированная проверка выявляет проблемные серверы, используйте этот чеклист для пошаговой диагностики и устранения неполадок.
- Повторная проверка настроек BIOS/UEFI: Физически или через IPMI войдите в интерфейс управления сервером Gigabyte. Убедитесь, что опция виртуализации ("Intel VT-x", "Intel VT-d", "AMD SVM Mode") активна и сохранена. На некоторых моделях серверных плат Gigabyte требуется также включить "Above 4G Decoding" и "SR-IOV Support" для полной функциональности. После изменения настроек выполните полную перезагрузку сервера, а не теплый рестарт ОС.
- Влияние Secure Boot: На системах с UEFI и активным Secure Boot загрузка сторонних модулей ядра, включая
kvm, может быть заблокирована. Временно отключите Secure Boot в разделе "Security" BIOS для тестирования. Если виртуализация заработает, подпишите модули KVM ключами платформы или настройте MOK (Machine Owner Key). - Ограничения оборудования: Убедитесь, что процессор сервера физически поддерживает аппаратную виртуализацию. Для Intel это технологии VT-x и VT-d (для ввода-вывода), для AMD - AMD-V и AMD-Vi. Проверьте спецификации процессора на сайте Gigabyte или Intel/AMD. Старые модели (например, Intel Xeon серии E5 v1/v2) могут иметь ограниченную поддержку.
- Проверка вложенной виртуализации (nested): Если на сервере планируется запускать виртуальные машины, которые сами будут работать как гипервизоры (например, для тестовых сред), активируйте nested виртуализацию. Для Intel выполните:
echo "options kvm-intel nested=1" | sudo tee /etc/modprobe.d/kvm-intel.conf, для AMD:echo "options kvm-amd nested=1" | sudo tee /etc/modprobe.d/kvm-amd.conf. Затем перезагрузите модули ядра или сервер. - Конфликты с другими технологиями: Некоторые технологии безопасности, такие как Intel SGX (Software Guard Extensions) или fTPM (Firmware TPM), могут конфликтовать с виртуализацией на уровне BIOS. Если проверка не проходит при корректных настройках, попробуйте отключить эти опции поэтапно. Подробнее о взаимодействии виртуализации и безопасности читайте в руководстве "Безопасность Linux-сервера: практический харденинг".
После внесения изменений повторно запустите Ansible Playbook для проверки. Автоматизация не только выявляет проблемы, но и ускоряет их устранение за счет четкого протокола диагностики.