Как определить, запущен ли Linux на физическом сервере или в виртуальной машине

Быстрые ссылки

• Virtual Machines and Hypervisors
• Команда dmidecode
• Команда lshw
• Команда hostnamectl
• Команда systemd-detect-virt
• Платформенно-чувствительный скрипт
• Когда виртуализация неочевидна

Что вы узнаете в этой статье

Вы научитесь: как с помощью стандартных команд Linux определить, работает ли система на «голом железе» или внутри виртуальной машины; какие команды лучше подходят для скриптов; какие нюансы и подводные камни встречаются на практике; список проверок и контрольных точек для разных ролей (админ, SRE, аудитор).

Important: Все примеры используют команды и вывод на русском языке в пояснениях, но сами команды (sudo, dmidecode, lshw и т. д.) остаются без перевода — они выполняются в терминале как есть.

Короткое пояснение терминов

• Виртуальная машина (VM): программная эмуляция компьютера, которая работает внутри хоста.
• Гипервизор: ПО, управляющее виртуальными машинами (тип 1 — bare-metal, тип 2 — внутри ОС).

Virtual Machines и гипервизоры — что важно знать

Традиционный сервер — физическое устройство с материнской платой, ЦП, ОЗУ и дисками. Виртуализация позволяет запускать несколько «виртуальных компьютеров» на одном физическом хосте, экономя ресурсы и упрощая масштабирование.

Гипервизор — это уровень ПО, который создаёт и изолирует виртуальные машины. Существуют гипервизоры типа 1 (на уровне железа, например VMware ESXi) и типа 2 (внутри хост-ОС, например VirtualBox). Linux с версии ядра 2.6.20 имеет встроенную поддержку KVM.

Почему это важно: многие команды в Linux читают аппаратную информацию, и в виртуальной среде эти поля обычно содержат подписи гипервизора (VirtualBox, QEMU, KVM, VMware и т. п.). Но в некоторых случаях подписи скрываются или заменяются, поэтому полезно иметь набор проверок.

Когда виртуализация может обмануть вас

• Контейнеры (Docker, LXC) не являются полноценными виртуальными машинами: они часто работают поверх хоста и не отображают отдельное «железо». Для них команды типа dmidecode или lshw часто возвращают данные хоста.
• Нестандартные образы и кастомные OVMF/BIOS могут подменять сведения о производителе.
• Облачные провайдеры (AWS, GCP, Azure) иногда предоставляют обобщённые или зашумлённые данные.

Note: Всегда комбинируйте несколько методов проверки — это уменьшает вероятность ложных срабатываний.

Команда dmidecode — подробный опрос DMI/SMBIOS

Команда dmidecode читает таблицы DMI/SMBIOS и выводит детальную информацию о системе: производителя, модель, серийный номер и т. п. Обычно требует root-привилегий.

Пример использования (вывод команды остаётся на английском, команды вводить без перевода):

sudo dmidecode -s system-product-name

На VirtualBox вы увидите строку вроде “VirtualBox”; в QEMU/KVM часто отображается “Standard PC (Q35)” или похожая запись. На физической машине вы получите модель материнской платы или производителя (например, MS-7B86 от Micro-Star International).

Плюсы:

• Подробно показывает поля производителя/модели.
• Хорош для инвентаризации и аудита.

Минусы:

• Требует sudo.
• Некоторые среды виртуализации подменяют или скрывают данные.

Краткая проверка с dmidecode:

• Если system-product-name или manufacturer содержат “VirtualBox”, “QEMU”, “VMware”, “KVM” — это виртуальная машина.
• Если показывается конкретная модель материнской платы или OEM — скорее физическая машина.

Команда lshw — подробный список аппаратных компонентов

lshw перечисляет конфигурацию аппаратуры: систему, память, процессоры, шины и т. п. Часто удобна опция -class system.

Примеры:

sudo lshw -class system

Альтернативный пример (GNOME Boxes / QEMU):

Вывод на физическом компьютере:

Что смотреть в lshw:

• Поле “product” показывает модель системы — виртуальные среды часто указывают VirtualBox, QEMU или “Standard PC”.
• Поле “vendor” обозначает поставщика аппаратуры.

Плюсы:

• Более детальный, чем простые утилиты.
• Полезен для диагностики и инвентаризации.

Минусы:

• Требует sudo для полного вывода.
• В контейнерах может показывать данные хоста.

Команда hostnamectl — удобно и без sudo (systemd)

hostnamectl показывает информацию о системе в systemd-системах. Команда не требует sudo и даёт строку Virtualization, если systemd может определить гипервизор.

Пример вывода в VirtualBox (с акцентом на строки):

Типичные поля, на которые стоит обратить внимание:

• icon-name — иногда содержит “-vm”.
• Chassis — “vm” для виртуальных машин.
• Virtualization — строка с названием гипервизора (oracle, kvm, vmware и т. п.).
• Hardware Vendor / Hardware Model — дают поставщика и модель.

Если Virtualization отсутствует, система, скорее всего, запущена на физическом оборудовании.

Плюсы:

• Не требует sudo.
• Подходит для быстрых проверок и выдачи компактного описания.

Минусы:

• Доступно только на systemd-системах.
• Не всегда даёт подробности о модели.

Команда systemd-detect-virt — короткий ответ для скриптов

systemd-detect-virt возвращает короткую строку: имя гипервизора или “none” для отсутствия виртуализации. Не требует sudo и хорошо подходит для автоматических проверок.

Примеры использования:

systemd-detect-virt

Возвращаемые значения: none, oracle, kvm, vmware, xen, lxc, openvz и др. (полный список можно получить через –list).

systemd-detect-virt --list | column

Плюсы:

• Идеально для скриптов (короткий и предсказуемый вывод).
• Не требует root.

Минусы:

• Работает только при наличии systemd.
• Возвращает только тип виртуализации, а не детали модели.

Платформенно-чувствительный скрипт — пример и пояснение

Ниже — минимальный Bash-скрипт, который печатает “Physical Hardware” или “Virtual Machine” в зависимости от вывода systemd-detect-virt. Скопируйте в файл platform.sh и сделайте исполняемым.

#!/bin/bash

shopt -s nocasematch

case $(systemd-detect-virt) in

none)
    echo "Physical Hardware"
    ;;

*)
    echo "Virtual Machine"
    ;;

esac

Пояснения:

• shopt -s nocasematch — делает сравнение регистронезависимым.
• “none” означает отсутствие виртуализации.
• В ветке “*” попадают все остальные значения (oracle, kvm, vmware и пр.).

Варианты улучшения скрипта:

• Заменить echo на установку переменной IS_VIRTUAL=true/false для использования в других частях скрипта.
• Обрабатывать конкретные гипервизоры через дополнительные case-ветви.
• Добавить логирование и режим отладки.

Критерии приёмки

• Скрипт корректно распознаёт среду на тестовой виртуальной машине (VirtualBox/KVM/VMware) и на физическом хосте.
• Скрипт возвращает корректный код выхода (0 для успешного определения, 2 для ошибок обнаружения).
• Для систем без systemd скрипт аккуратно падает с понятным сообщением.

Дополнительные методы и альтернативы

Помимо перечисленных команд, можно использовать следующие способы проверки:

• Просмотр dmesg на наличие строк вроде “Hypervisor detected” или сообщений, специфичных для гипервизора.
• Проверка /proc/cpuinfo на флаги, например presence of “hypervisor” в поле flags.
• Утилиты virt-what (отдельный пакет) дают удобное распознавание гипервизора.
• Просмотр ACPI таблиц через /sys или /proc, а также проверка серийных номеров оборудования.

Пример проверки cpuinfo:

grep -i hypervisor /proc/cpuinfo || echo "No hypervisor flag"

Если флаг “hypervisor” присутствует — почти гарантированно VM, но его отсутствие не означает физический хост (иногда гипервизор не помечает CPU).

Контейнеры vs Виртуальные машины — различия и как их заметить

Контейнеры (Docker, Podman, LXC) делят ядро хоста и обычно не создают отдельную виртуальную среду аппаратуры. Проверки для контейнеров:

• systemd-detect-virt может вернуть значения типа “container” или конкретное имя контейнера.
• Проверка /proc/1/cgroup и /proc/self/cgroup покажет принадлежность процессов к cgroup контейнера.
• Отсутствие отдельных ACPI/SMBIOS записей — признак контейнерной среды.

Когда команды ошибаются — типичные подводные камни

• Облачные образы: провайдеры могут заполнять DMI полями, которые не однозначно указывают на виртуальную среду.
• Скрытая/переопределённая информация: гипервизор может изменить записи SMBIOS, чтобы скрыть себя.
• Необычные BIOS/UEFI: старые или кастомные прошивки могут возвращать неполные или неверные поля.

Counterexample (когда не сработает): гипервизор может установить manufacturer в значение OEM, совпадающее с физическим сервером, и тогда dmidecode/lshw дадут ложное ощущение физического оборудования.

Роль-ориентированные контрольные списки

Администратор (операции):

• Проверить systemd-detect-virt — быстрый ответ.
• Использовать hostnamectl для читаемого вывода.
• Для инвентаризации — dmidecode + lshw.
• При подозрениях — проверка флагов в /proc/cpuinfo и dmesg.

SRE / DevOps:

• Добавить определение среды в автоматические плейбуки (Ansible/Puppet) на старте.
• Логировать результат systemd-detect-virt в метаданные контейнера/VM.
• Тестировать на целевых гипервизорах (KVM, VMware, Hyper-V, Xen).

Аудитор / безопасность:

• Проверить целостность DMI/SMBIOS информации.
• Сопоставить серийные номера/производителя с инвентарём.
• Зафиксировать случаи, когда виртуализация маскируется.

Краткая методология тестирования (мини-SOP)

1. Вначале запустить systemd-detect-virt. Если возвращает значение отличное от “none”, пометить как VM.
2. Если “none”, выполнить hostnamectl и dmidecode для подтверждения.
3. Запустить lshw для сбора деталей о модели и поставщике.
4. Проверить /proc/cpuinfo на флаги hypervisor и dmesg на гипервизор-специфичные сообщения.
5. Записать результаты в инвентарную базу и прикрепить заметку о методе проверки.

Тест-кейсы / критерии приёмки

• TC1: На VirtualBox systemd-detect-virt возвращает “oracle” или “vbox” и скрипт помечает систему как виртуальную.
• TC2: На KVM systemd-detect-virt возвращает “kvm”; dmidecode/lshw показывают “QEMU” или “Standard PC”.
• TC3: На физическом сервере systemd-detect-virt возвращает “none”, а dmidecode указывает производителя OEM и модель платы.
• TC4: В контейнере проверки показывают отсутствие ACPI/SMBIOS и /proc/cgroup указывает на контейнер.

Критерий успешности: в 4/4 тест-кейсов распознавание совпадает с истинным состоянием.

Безопасность и приватность

• Команды вроде dmidecode и lshw читают аппаратные идентификаторы и серийные номера; храните их безопасно.
• В облачных и многопользовательских средах не раскрывайте результаты dmidecode публично — они могут содержать информацию, которую злоумышленник использует для таргетинга.

Совместимость и заметки по дистрибутивам

• systemd-detect-virt и hostnamectl доступны только в системах с systemd (Debian/Ubuntu, Fedora, CentOS >=7 и др.).
• На дистрибутивах без systemd используйте dmidecode, lshw и /proc-файлы.
• Для неполных окружений (minimal live-CD) убедитесь, что пакеты lshw и dmidecode установлены.

Диаграмма принятия решения (Mermaid)

flowchart TD
  A[Запустить systemd-detect-virt] --> B{Вернулось 'none'?}
  B -- Да --> C[Запустить hostnamectl и dmidecode]
  B -- Нет --> D[Пометить как VM и дополнительная проверка: dmidecode,lshw]
  C --> E{hostnamectl содержит Virtualization?}
  E -- Да --> D
  E -- Нет --> F[Проверить /proc/cpuinfo и dmesg]
  F --> G{Найдены признаки гипервизора?}
  G -- Да --> D
  G -- Нет --> H[Скорее всего физическое оборудование]

Примеры практических сценариев

• Удалённый администратор: если вы подключаетесь по SSH и не уверены, запросите output systemd-detect-virt и hostnamectl — это даст быстрое представление.
• Скрипты развёртывания: пометьте образы и ветви выполнения в зависимости от того, физический это хост или VM (например, инициализация RAID только на физическом оборудовании).
• Инвентаризация и аудит: используйте dmidecode + lshw для заполнения реестра оборудования.

Edge-case gallery (типичные редкие конфигурации):

• Nested virtualization — гипервизор внутри гипервизора; системы могут показывать флаги hypervisor, но dmidecode укажет верхний уровень.
• OEM-образ, где SMBIOS маскируется под конкретный бренд — нужно сверять серийники с инвентарём.

Короткий глоссарий (1 строка)

• SMBIOS/DMI: стандарт для передачи сведений о системе между firmware и ОС; используется dmidecode.
• ACPI: интерфейс энергоменеджмента и конфигурации, который иногда содержит подсказки о среде.
• Hypervisor flag: флаг в /proc/cpuinfo, указывающий на присутствие гипервизора.

Заключение и рекомендации

• Для автоматических задач используйте systemd-detect-virt — быстро и надёжно на systemd-системах.
• Для аудита и инвентаризации комбинируйте dmidecode и lshw для получения подробных данных о поставщике и модели.
• Не полагайтесь на единственную команду — комбинируйте методы (hostnamectl, /proc/cpuinfo, dmesg) для надёжности.

Summary: Умение отличать виртуальную среду от физического хоста важно для правильной настройки, мониторинга и безопасности. Набор простых команд и контрольных проверок позволит вам принимать грамотные решения.

Если хотите, я могу:

• Подготовить готовый Ansible-таск, который автоматически пометит хосты в инвентаре как VM/physical.
• Сгенерировать чек-лист для аудита оборудования и виртуальных инстансов.