Как проверить работу QEMU Guest Agent?

Проверьте связь с хоста командой virsh qemu-agent-command vm1 '{"execute":"guest-ping"}'. Успешный ответ означает, что libvirt может обратиться к агенту. Для работы агент должен быть установлен и запущен внутри гостевой ОС, а в конфигурации выключенной VM должен быть добавлен канал QEMU Guest Agent org.qemu.guest_agent.0.

Как вывести список виртуальных машин через virsh?

Используйте virsh -c qemu:///system list --all. Команда покажет как работающие, так и выключенные домены системного экземпляра libvirt. Явное указание URI важно: без параметра -c клиент может подключиться к другому экземпляру libvirt, например пользовательскому qemu:///session, где нужной VM нет.

Почему есть флаг vmx или svm, но KVM не работает?

Наличие vmx или svm подтверждает возможности CPU, но не гарантирует доступность KVM. Аппаратная виртуализация может быть выключена в BIOS/UEFI, драйвер KVM — недоступен ядру, а хост может работать внутри VM без включённой nested virtualization. Проверьте /dev/kvm, модули kvm и kvm_intel либо kvm_amd, а также журналы ядра.

Когда выбирать qemu:///system, а когда qemu:///session?

Для серверных VM обычно выбирают qemu:///system. Этот экземпляр libvirt управляется системными службами и может использовать системные сети, bridge и устройства хоста при наличии прав. qemu:///session рассчитан на непривилегированные пользовательские сценарии: ресурсы обычно размещаются в домашнем каталоге, а доступ к системным сетям и устройствам ограничен.

Получит ли VM адрес в физической сети через default?

Нет, не автоматически. Сеть libvirt default обычно является частной виртуальной сетью с NAT: гостевая VM получает исходящий доступ через хост при корректной связности хоста, но не становится полноценным узлом физической сети. Для подключения VM к внешнему сегменту требуется отдельно настроить подходящую схему, например bridge.

Может ли диск QCOW2 заполнить хранилище хоста?

Да. QCOW2 обычно выделяет физическое место по мере записи данных гостевой ОС, поэтому файл может быть меньше заданного виртуального размера. Однако при росте данных VM том хоста способен заполниться. Свободное место нужно контролировать отдельно, особенно при thin-размещении, использовании снимков и цепочек backing file.

KVM, QEMU и libvirt в Linux: установка, VM, virsh и Guest Agent

KVM использует аппаратную виртуализацию CPU в ядре Linux, QEMU запускает процесс виртуальной машины и предоставляет ей виртуальное оборудование, а libvirt даёт единый интерфейс управления этим стеком. После проверки хоста можно создать виртуальную машину из ISO или готового образа через virt-manager либо virt-install, а затем управлять ею через virsh. QEMU Guest Agent устанавливается отдельно внутри гостевой ОС и расширяет доступные операции управления.

За что отвечают KVM, QEMU и инструменты libvirt

Компонент	Роль на Linux-хосте
KVM	Подсистема ядра Linux для аппаратно ускоренного выполнения кода гостевой ОС на CPU хоста. Для x86 обычно используются модули `kvm_intel` или `kvm_amd`.
QEMU	Процесс VM и модель её виртуального оборудования: CPU, памяти, дисков, сетевых адаптеров, контроллеров и устройств. QEMU может использовать KVM для ускорения.
libvirt	API, фоновые службы и хранилище конфигураций. Представляет VM как домены с XML-конфигурацией и управляет QEMU/KVM, сетями и пулами хранения.
virt-manager	Графический клиент libvirt. Его можно запускать на рабочей станции и подключать к локальному или удалённому хосту способами, предусмотренными libvirt.
virsh	Консольный клиент libvirt для просмотра и управления доменами, сетями и хранилищами.
virt-install	Утилита командной строки для создания VM и передачи параметров установки или импорта в libvirt.

KVM, QEMU и libvirt не заменяют друг друга. QEMU умеет работать и без KVM, включая эмуляцию других архитектур, но в этой статье он рассматривается как компонент серверного стека QEMU/KVM/libvirt. Наличие QEMU не доказывает, что гостевая ОС будет запущена с аппаратным ускорением KVM.

Не смешивайте управление QEMU и libvirt без необходимости

virt-manager, virsh и virt-install работают с конфигурацией libvirt. Если запускать QEMU напрямую или менять его параметры вне libvirt, эти изменения могут не попасть в XML домена и не отразиться в ожидаемой конфигурации при следующем запуске VM.

Проверьте готовность хоста к KVM

Для аппаратно ускоренной виртуализации нужны совместимые CPU и платформа, включённая аппаратная виртуализация в BIOS/UEFI, а также доступный драйвер KVM в ядре Linux. Дальнейшие проверки vmx, svm, Intel VT-x и AMD-V относятся к хостам x86-64. Для ARM64 и других поддерживаемых KVM архитектур признаки готовности и настройки платформы отличаются — используйте документацию ядра Linux, платформы и дистрибутива. На x86 флаг vmx у Intel или svm у AMD подтверждает возможность CPU, но сам по себе не подтверждает, что виртуализация включена в firmware, разрешена для вложенной VM или доступна текущему ядру.

Минимальная проверка Linux-хоста

Команды подходят для большинства дистрибутивов Linux. Выполняйте их до установки VM.

1
Проверьте возможности процессора
Выполните lscpu. В строке Virtualization обычно будет указано VT-x или AMD-V; альтернативно проверьте флаги vmx/svm в /proc/cpuinfo. Если флагов нет, проверьте модель CPU и настройки BIOS/UEFI. Если Linux сам запущен внутри VM, потребуется поддержка и включение nested virtualization на внешнем гипервизоре.
2
Проверьте доступность KVM для ядра
Проверьте наличие /dev/kvm и загруженные модули. Ожидаемый результат — устройство существует, а среди модулей есть kvm и, как правило, kvm_intel либо kvm_amd. Отсутствие устройства после включения VT-x или AMD-V требует проверки журналов ядра, настроек BIOS/UEFI и ограничений среды, где работает хост.
3
Оцените ресурсы
Проверьте свободную память, ёмкость и производительность хранилища, а также сетевую связность. Для первой VM заранее определите число vCPU, объём RAM, размер виртуального диска и способ подключения к сети. Ресурсы, оставленные хостовой ОС, не следует назначать гостям как гарантированно свободные.
4
Проверьте настройку firmware
Убедитесь, что в BIOS/UEFI включена CPU Virtualization: Intel VT-x либо AMD-V. Названия, расположение параметров и необходимость полного выключения питания зависят от сервера, поколения платформы и версии firmware. Пошаговая процедура для этой части приведена в статье «Как включить Intel VT-x, AMD-V и IOMMU в BIOS/UEFI сервера».

Быстрая проверка CPU, устройства KVM и модулей ядра.

lscpu | grep -i virtualization
ls -l /dev/kvm
lsmod | grep '^kvm'

Вывод:

Типичный успешный результат содержит `Virtualization: VT-x` или `AMD-V`, устройство `/dev/kvm` и модули `kvm` с `kvm_intel` либо `kvm_amd`.

IOMMU — отдельная возможность

Intel VT-d или AMD IOMMU нужны для сценариев вроде PCIe passthrough, но не обязательны для обычной VM с виртуальными дисками и сетевыми адаптерами. Их настройка рассматривается отдельно в статье о GPU passthrough и вложенной виртуализации.

Установка KVM, QEMU и libvirt

Названия пакетов различаются между семействами дистрибутивов, их релизами и подключёнными репозиториями. В типичной установке нужны QEMU с поддержкой KVM, службы и клиент libvirt, virt-install; virt-manager нужен только там, где требуется графический клиент. На минимальном сервере можно обойтись virsh и virt-install, а virt-manager запустить на отдельной рабочей станции.

Установите компоненты для своего семейства Linux

1
Debian и Ubuntu
На x86-хосте установите qemu-system-x86, libvirt-daemon-system, libvirt-clients, virtinst и при необходимости virt-manager. В Ubuntu также доступен метапакет qemu-kvm; наличие и назначение этого имени в Debian зависят от выпуска. Пакет libvirt-daemon-system добавляет системную интеграцию libvirt, а libvirt-clients предоставляет virsh.
2
Fedora, RHEL и совместимые системы
Установите qemu-kvm, libvirt, libvirt-client, virt-install и при необходимости virt-manager. В некоторых выпусках состав поставляется через группу виртуализации или разделяется на дополнительные подпакеты, включая драйвер QEMU для libvirt. Если пакет не найден, проверьте подключённые репозитории и документацию именно вашего выпуска.
3
Проверьте архитектуру служб libvirt
В современных системах libvirt может использовать модульные демоны и socket activation: VM обслуживает virtqemud, виртуальные сети — virtnetworkd, а хранилища — virtstoraged. В других выпусках эти функции выполняет монолитный libvirtd. Проверьте доступные units и включайте только вариант, предусмотренный дистрибутивом. Затем выполните virsh -c qemu:///system uri.

debian-ubuntu.sh

sudo apt update
sudo apt install qemu-system-x86 libvirt-daemon-system libvirt-clients virtinst
# Только если графический клиент нужен на этом компьютере:
sudo apt install virt-manager

# Проверка соединения с системным libvirt
virsh -c qemu:///system uri

fedora-rhel.sh

sudo dnf install qemu-kvm libvirt libvirt-client virt-install
# Только если графический клиент нужен на этом компьютере:
sudo dnf install virt-manager

# Проверка соединения с системным libvirt
virsh -c qemu:///system uri

libvirt-services.sh

# Сначала посмотрите, какие units установлены
systemctl list-unit-files 'virtqemud*' 'virtnetworkd*' 'virtstoraged*' 'libvirtd*'

# Модульный вариант: выполните эту команду только если он используется выпуском
# sudo systemctl enable --now virtqemud.socket virtnetworkd.socket

# ИЛИ монолитный вариант: выполните только если выпуск использует libvirtd
# sudo systemctl enable --now libvirtd.socket

Не включайте оба варианта служб наугад: на конкретном хосте используйте тот вариант, который установлен и поддерживается выпуском. Socket activation запускает нужный демон при обращении клиента к сокету. Точные имена units, состав модульных демонов и их конфигурация зависят от версии libvirt и дистрибутива; для нестандартной установки сверяйтесь с официальными руководствами libvirt и вашего дистрибутива.

Проверяет, что текущий пользователь может подключиться к системному экземпляру libvirt.

virsh -c qemu:///system list --all

Вывод:

Даже при отсутствии VM команда должна вывести заголовок таблицы со столбцами `Id`, `Name` и `State`. Ошибка прав означает, что нужно настроить разрешённый механизм доступа дистрибутива — например, polkit или членство в предусмотренной группе — а не запускать все административные команды от root без необходимости.

qemu:///system и qemu:///session: какое подключение выбрать

URI libvirt Назначение и ограничения

qemu:///system Системный экземпляр libvirt. Домены и ресурсы управляются системными службами, обычно размещаются в системных каталогах и могут использовать системные виртуальные сети, bridge и устройства хоста при наличии прав. Это обычный выбор для серверных VM.

qemu:///session Пользовательский экземпляр для непривилегированного пользователя. Ресурсы обычно находятся в домашнем каталоге пользователя, а возможности доступа к системным сетям, bridge и устройствам ограничены. Подходит для пользовательских и локальных сценариев, но не заменяет системную конфигурацию сервера.

URI libvirt	Назначение и ограничения
`qemu:///system`	Системный экземпляр libvirt. Домены и ресурсы управляются системными службами, обычно размещаются в системных каталогах и могут использовать системные виртуальные сети, bridge и устройства хоста при наличии прав. Это обычный выбор для серверных VM.
`qemu:///session`	Пользовательский экземпляр для непривилегированного пользователя. Ресурсы обычно находятся в домашнем каталоге пользователя, а возможности доступа к системным сетям, bridge и устройствам ограничены. Подходит для пользовательских и локальных сценариев, но не заменяет системную конфигурацию сервера.

URI задают явно через -c, например virsh -c qemu:///system list --all. Если не указывать URI, клиент может выбрать соединение по умолчанию, не совпадающее с тем, где создана VM. virt-manager и virsh могут управлять одними и теми же доменами, когда подключены к одному URI.

Подготовьте диск и сеть для первой VM

Для VM потребуется ISO установщика либо готовый образ гостевой ОС, место под диск, RAM, vCPU и сеть. В типичной установке libvirt сеть default — это частная виртуальная сеть с NAT: гостю обычно доступен исходящий трафик через хост при корректной связности самого хоста, но VM не становится автоматически полноценным узлом физической сети. Для присутствия VM во внешней сети нужно отдельно настроить подходящий способ подключения, например bridge.

Показывает виртуальные сети libvirt и состояние сети `default`.

virsh -c qemu:///system net-list --all

start-default-network.sh

sudo virsh -c qemu:///system net-start default
sudo virsh -c qemu:///system net-autostart default
virsh -c qemu:///system net-list --all

Команды запускают default, если она существует, но остановлена. Если сети нет в списке, не создавайте произвольную конфигурацию для рабочего сегмента: проверьте установленные компоненты libvirt и спроектируйте сеть отдельно. Bridge, VLAN, подключение к физическому uplink и разделение management, storage и VM-трафика требуют отдельной схемы — см. «Сети виртуальных машин в ESXi, Hyper-V и Proxmox VE: vSwitch, VLAN и bridge».

Размер виртуального диска не равен свободному месту на хосте

Формат QCOW2 поддерживает copy-on-write и обычно выделяет место по мере записи данных гостем. Поэтому файл может занимать меньше своего виртуального размера, но хранилище всё равно нужно контролировать: при росте данных VM физический том может заполниться. Thin-размещение, снимки и цепочки backing file требуют отдельного контроля.

Создайте первую VM через virt-manager

Создание VM из ISO в графическом интерфейсе

Порядок подходит для virt-manager, подключённого к qemu:///system на локальном или удалённом хосте.

1
Откройте системное подключение
Добавьте или выберите подключение QEMU/KVM с URI qemu:///system. На серверном хосте графическая среда не обязательна: virt-manager можно использовать с администраторской рабочей станции, настроив безопасное удалённое соединение предусмотренным libvirt способом.
2
Выберите источник установки
Запустите создание новой VM и укажите локальный ISO или другой поддерживаемый источник установки. ISO должен быть доступен тому компьютеру или хосту, для которого выбран способ передачи носителя.
3
Назначьте вычислительные ресурсы
Укажите число vCPU и объём памяти, оставив ресурсы для хостовой ОС и других нагрузок. Для первой проверки достаточно небольших значений, совместимых с выбранной гостевой ОС; подбор ресурсов под рабочую нагрузку рассматривается в статье о производительности и метриках виртуализации.
4
Создайте виртуальный диск
Выберите пул или путь хранения и задайте виртуальный размер диска. Для типичной Linux VM подходит QCOW2 и контроллер с VirtIO, если гостевая ОС содержит нужный драйвер. При установке некоторых Windows-систем драйвер VirtIO может потребоваться загрузить отдельно.
5
Подключите сеть и запустите VM
Выберите сеть default, если нужен типичный NAT-сценарий. Проверьте имя VM, параметры диска и сети, затем завершите создание. После запуска откроется графическая консоль установщика; дальнейшая установка и защита гостевой ОС выполняются по её профильной инструкции.

Интерфейс virt-manager зависит от версии

Названия экранов, кнопок, доступных моделей устройств и параметров XML меняются между версиями virt-manager, libvirt, QEMU и дистрибутивами. Для нестандартных UEFI-настроек, контроллеров, архитектур и удалённых подключений используйте официальные руководства соответствующих компонентов, но сохраняйте принцип: VM создаётся в том же URI, которым затем управляют virsh и virt-manager.

Создайте VM через virt-install

Ниже — пример для системного libvirt, ISO в /var/lib/libvirt/boot/ и сети default. Значения имени, пути, размера диска, памяти и vCPU замените на свои. Параметры virt-install и доступные значения зависят от версии утилиты, libvirt и QEMU; перед использованием на рабочем хосте проверьте virt-install --help и документацию своего выпуска.

Создаёт VM `vm1` из ISO с диском QCOW2 виртуального размера 20 GiB, двумя vCPU, 2 GiB RAM и NAT-сетью `default`. VNC выбран как переносимый пример; доступные графические backend зависят от сборки QEMU и дистрибутива.

sudo virt-install \
  --connect qemu:///system \
  --name vm1 \
  --memory 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/vm1.qcow2,size=20,format=qcow2,bus=virtio \
  --cdrom /var/lib/libvirt/boot/guest.iso \
  --os-variant generic \
  --network network=default,model=virtio \
  --graphics vnc \
  --console pty,target.type=serial \
  --noautoconsole

После выполнения команда должна создать домен и запустить установщик. Если сообщается, что сеть default отсутствует или неактивна, вернитесь к проверке сетей. Если libvirt не может создать диск, проверьте свободное место, права на каталог /var/lib/libvirt/images/ и доступность ISO. Установку ОС после старта установщика эта инструкция не рассматривает: используйте документацию выбранной гостевой Linux- или Windows-системы.

Импортирует существующий образ вместо запуска установщика. Образ должен быть совместим с выбранной архитектурой, загрузочным режимом и виртуальными устройствами VM; доступные графические backend зависят от QEMU и дистрибутива.

sudo virt-install \
  --connect qemu:///system \
  --name imported-vm \
  --memory 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/imported-vm.qcow2,format=qcow2,bus=virtio \
  --import \
  --os-variant generic \
  --network network=default,model=virtio \
  --graphics vnc

Базовое управление VM через virsh

Во всех командах ниже vm1 — имя домена. Добавляйте -c qemu:///system, если URI по умолчанию не настроен или нужно исключить ошибочное подключение к пользовательской сессии.

Задача	Команда	Ожидаемый результат
Список всех VM	`virsh -c qemu:///system list --all`	Показывает работающие и выключенные домены.
Состояние одной VM	`virsh -c qemu:///system domstate vm1`	Например, `running`, `shut off`, `paused`.
Запуск	`virsh -c qemu:///system start vm1`	Домен переходит в состояние `running`.
Штатное выключение	`virsh -c qemu:///system shutdown vm1`	Отправляет гостю запрос на выключение; реакция зависит от ACPI, гостевой ОС и её политики.
Текстовая консоль	`virsh -c qemu:///system console vm1`	Подключает к настроенной последовательной консоли VM. Выйти можно сочетанием `Ctrl+]`.

Не используйте destroy как обычное выключение

virsh destroy vm1 немедленно прекращает процесс VM и аналогичен аварийному отключению питания. Он может понадобиться только в контролируемой аварийной ситуации. Если shutdown не завершает работу, сначала проверьте состояние гостя и доступную консоль.

Команда virsh console требует последовательного устройства в конфигурации VM и настроенной консоли внутри гостя. Если её нет, это не означает, что VM не работает: используйте графическую консоль virt-manager или добавьте последовательный интерфейс по документации гостевой ОС и libvirt.

Установите и подключите QEMU Guest Agent

QEMU Guest Agent — это служба внутри гостевой ОС, а не часть хостового QEMU. Для связи нужен специальный канал между гостем и хостом; обычно это virtio-serial channel с именем org.qemu.guest_agent.0. Агент не нужен для загрузки VM и не заменяет SSH, RDP, WinRM или иной сетевой доступ к гостю.

Подключение QEMU Guest Agent

1
Добавьте канал в конфигурацию VM
При выключенной VM добавьте в virt-manager устройство Channel и выберите тип QEMU Guest Agent, если он предлагается интерфейсом. Альтернатива — изменить XML домена через virsh edit. После запуска VM проверьте, что канал присутствует в её конфигурации.
2
Установите агент в гостевой Linux
В Debian/Ubuntu и Fedora/RHEL-подобных гостевых системах пакет обычно называется qemu-guest-agent. Установите его штатным менеджером пакетов гостевой ОС и включите одноимённую службу. В Windows агент обычно поставляется в составе набора драйверов и инструментов VirtIO; имя службы и способ установки зависят от поставляемого комплекта.
3
Проверьте службу в госте
В Linux выполните systemctl status qemu-guest-agent. Ожидается состояние active (running). Если служба не стартует, проверьте, что канал добавлен в VM и доступен гостевой ОС.
4
Проверьте агента с хоста
Выполните virsh qemu-agent-command vm1 '{"execute":"guest-ping"}'. Успешный ответ подтверждает связь libvirt с агентом. Команда virsh domifaddr vm1 --source agent может показать IP-адреса, если агент, гостевая ОС и сетевая конфигурация предоставляют эти сведения.

guest-linux-debian-ubuntu.sh

# Debian/Ubuntu внутри гостевой ОС
sudo apt update
sudo apt install qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

guest-linux-fedora-rhel.sh

# Fedora/RHEL-подобная гостевая ОС
sudo dnf install qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

domain-channel.xml

<channel type='unix'>
  <target type='virtio' name='org.qemu.guest_agent.0'/>
</channel>

Этот XML-фрагмент размещают внутри элемента <devices> домена. libvirt обычно создаёт и обслуживает Unix-сокет канала на стороне хоста; вручную задавать путь сокета без необходимости не следует. Точные параметры XML и способ добавления устройства зависят от версии libvirt, QEMU и virt-manager.

Проверяет ответ агента и запрашивает адреса интерфейсов, которые агент может сообщить.

virsh -c qemu:///system qemu-agent-command vm1 '{"execute":"guest-ping"}'
virsh -c qemu:///system domifaddr vm1 --source agent

Что даёт агент

В зависимости от версии агента, libvirt, гостевой ОС и разрешённой политики агент может сообщать сведения о госте и интерфейсах, выполнять штатное выключение, синхронизацию времени, заморозку и разморозку файловой системы для согласованных операций, а также другие поддерживаемые команды. Нельзя рассчитывать, что он всегда сообщит IP-адрес или гарантированно корректно выключит любую гостевую ОС.

Проверьте результат

Команда ls -l /dev/kvm подтверждает, что устройство KVM доступно хосту.
virsh -c qemu:///system list --all показывает созданную VM.
virsh -c qemu:///system domstate vm1 возвращает ожидаемое состояние: после запуска — running.
virsh -c qemu:///system net-list --all показывает активную сеть default, если она была выбрана для VM.
Графическая консоль virt-manager или настроенная последовательная консоль показывает загрузку гостевой ОС.
После установки агента qemu-agent-command с guest-ping получает ответ от VM.

Для выбора между KVM/QEMU/libvirt, VMware, Hyper-V, Proxmox VE и Xen используйте сравнение платформ серверной виртуализации. Создание первой VM не заменяет проектирование резервного копирования, сетей, мониторинга и восстановления; снимки и шаблоны также не являются резервной копией — их границы разобраны в статье о клонах, шаблонах и снимках VM.

Термины в статье

Аппаратная виртуализация: Аппаратная виртуализация — способ запуска ВМ с поддержкой процессора и платформы, где привилегированные операции гостя обрабатываются специальными механизмами CPU, а не только программной эмуляцией.
Виртуализация: Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Виртуальная сеть: Виртуальная сеть — логическая сеть, реализованная программными средствами для связи ВМ и других виртуальных нагрузок между собой и, при необходимости, с физической сетью.
Виртуальное оборудование: Виртуальное оборудование — логическая аппаратная платформа, которую гипервизор предоставляет ВМ: виртуальные процессоры, память, устройства и системную прошивку.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Демон: Демон — обычно длительно работающий неинтерактивный процесс, который в фоне выполняет системную, сетевую или прикладную функцию.
Менеджер пакетов: Менеджер пакетов — средство установки, обновления, удаления и учёта программных пакетов; высокоуровневые менеджеры также работают с репозиториями и разрешают зависимости.
Процесс: Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Системная служба: Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Снимок состояния: Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Сокетная активация: Сокетная активация — запуск службы при активности на заранее открытом диспетчером сокете с передачей службе его файлового дескриптора.
Шаблон виртуальной машины: Подготовленный объект платформы виртуализации с образом ОС и заданной конфигурацией для повторяемого развертывания новых виртуальных машин.
Эмуляция: Эмуляция — программное воспроизведение устройства или аппаратной платформы, при котором гостевая система использует их интерфейс без прямого доступа к реальному оборудованию.
Ядро Linux: Ядро Linux — центральный компонент ОС, управляющий аппаратными ресурсами и предоставляющий системные интерфейсы; оно не включает пользовательские утилиты и менеджер пакетов.
Debian: Debian — универсальный дистрибутив Linux с пакетами DEB и системой APT, известный консервативной веткой Stable и разделением репозиториев по веткам разработки.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
Hyper-V: Платформа виртуализации Microsoft с гипервизором типа 1, доступная как роль Windows Server и компонент Windows 10/11 Pro, Enterprise и Education.
Intel VT-d: Intel VT-d — технология аппаратной виртуализации ввода-вывода Intel, ограничивающая DMA устройств и позволяющая безопаснее назначать их виртуальным машинам.
Intel VT-x: Intel VT-x — расширение процессоров Intel для аппаратной виртуализации x86, вводящее режимы VMX для выполнения гостевых ОС под контролем гипервизора без полной программной эмуляции.
IOMMU: IOMMU — аппаратный блок, который преобразует адреса DMA-запросов устройств в адреса физической памяти и ограничивает их доступ; нужен для изоляции и прямого назначения PCIe-устройств ВМ.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
libvirt: libvirt — открытый набор библиотек, API, служб и утилит для унифицированного управления ВМ, контейнерами, сетями и хранилищами на платформах виртуализации.
Nested Virtualization: Вложенная виртуализация — возможность запускать гипервизор и виртуальные машины второго уровня внутри обычной виртуальной машины.
Proxmox: Открытая платформа серверной виртуализации на базе Debian, использующая QEMU/KVM для виртуальных машин и LXC для системных Linux-контейнеров.
QCOW2: QCOW2 — файловый формат виртуального диска QEMU с выделением места по мере записи, поддержкой backing file, снимков и необязательных функций сжатия или шифрования.
QEMU: QEMU — открытый эмулятор вычислительных систем и монитор виртуальных машин; в Linux он может использовать KVM для виртуализации с аппаратным ускорением.
QEMU Guest Agent: QEMU Guest Agent — служба в гостевой ОС, через которую QEMU или система управления получает сведения о госте и выполняет в нём разрешённые операции по настроенному каналу связи.
SSH: SSH — криптографический сетевой протокол для удалённого доступа и передачи данных, аутентифицирующий стороны и защищающий сеанс от перехвата.
Uplink: Uplink — соединение или интерфейс, ведущий от устройства либо локального сегмента к вышестоящей сети; в виртуализации — подключение виртуального коммутатора к физической сети.
vCPU: vCPU — виртуальный логический процессор, предоставляемый виртуальной машине; гипервизор планирует его выполнение на процессорных ресурсах хоста.
virsh: virsh — консольная утилита libvirt для управления виртуальными машинами, сетями и хранилищами через локальное или удалённое соединение с libvirt.
virt-install: virt-install — утилита командной строки для создания и установки виртуальных машин через libvirt с заданием ресурсов, дисков, сети и источника установки.
virt-manager: virt-manager — графический клиент управления виртуализацией через libvirt, создающий и администрирующий ВМ на локальных или удалённых хостах, обычно с KVM/QEMU.
VirtIO: VirtIO — стандарт паравиртуальных устройств для виртуальных машин, заменяющий эмулируемое оборудование интерфейсом, оптимизированным для обмена с гипервизором.
VMware: VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
Xen: Xen — гипервизор первого типа, работающий непосредственно на сервере и поддерживающий режимы виртуализации HVM, PV и PVH.