Администрирование KVM на Fedora 44: от базовой настройки до продвинутого управления

Подготовка сервера и установка стека виртуализации KVM на Fedora 44

Представьте ситуацию: вы получили доступ к чистому серверу с установленной Fedora 44 по SSH, и ваша задача — превратить его в отказоустойчивый гипервизор. Казалось бы, достаточно выполнить dnf install qemu-kvm, но дьявол кроется в деталях. Ошибка в проверке аппаратной поддержки виртуализации или неверно выбранный профиль электропитания могут привести к тому, что производительность гостевых систем будет на 30–40% ниже потенциально возможной, а диагностика случайных зависаний превратится в бесконечный поиск иголки в стоге сена.

Фундамент гипервизора: проверка аппаратных возможностей

Прежде чем вводить первую команду по установке пакетов, необходимо убедиться, что «железо» готово к роли гипервизора. KVM (Kernel-based Virtual Machine) — это не эмулятор, а полноценный модуль ядра, который превращает Linux в гипервизор типа 1 (bare-metal), используя расширения процессора Intel VT-x или AMD-V.

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

grep -E 'svm|vmx' /proc/cpuinfo

В этом выводе нас интересуют два ключевых значения:

1. vmx — для процессоров Intel.
2. svm — для процессоров AMD.

Если команда не вернула ничего, дальнейшая установка KVM не имеет смысла: система будет использовать медленную программную эмуляцию (QEMU без KVM), что неприемлемо для серверных задач. Однако наличие флага в /proc/cpuinfo еще не гарантирует, что расширения активированы. Более надежный метод — использование утилиты virt-host-validate. Поскольку она входит в состав пакета libvirt-client, который мы установим чуть позже, на данном этапе стоит заглянуть в настройки BIOS/UEFI и убедиться, что параметры Intel Virtualization Technology или AMD SVM Mode находятся в состоянии Enabled.

Важным нюансом является поддержка IOMMU (Intel VT-d или AMD-Vi). Эта технология позволяет передавать PCI-устройства (например, сетевые карты или GPU) напрямую в виртуальную машину. Даже если вы не планируете делать это сегодня, правильная инициализация IOMMU на этапе подготовки сэкономит часы работы в будущем.

Подготовка операционной системы Fedora 44

Fedora 44 — это передовой дистрибутив, который часто служит полигоном для технологий, попадающих затем в Red Hat Enterprise Linux (RHEL). Это означает, что мы имеем дело с самым свежим ядром и актуальными версиями QEMU и Libvirt. Перед установкой стека виртуализации необходимо привести систему в актуальное состояние и настроить базовые параметры безопасности.

Обновление и очистка

Обновим все компоненты системы, чтобы избежать конфликтов версий между ядром и модулями KVM:

sudo dnf update -y

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

Настройка параметров ядра (Kernel Boot Parameters)

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

Отредактируйте файл /etc/default/grub. Найдите строку GRUB_CMDLINE_LINUX и добавьте в неё:

• Для Intel: intel_iommu=on iommu=pt
• Для AMD: amd_iommu=on iommu=pt

Параметр iommu=pt (pass-through) критически важен: он предотвращает попытки ядра Linux затронуть устройства, которые не используются хостом, что улучшает производительность ввода-вывода.

После внесения изменений обновите конфигурацию GRUB:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Установка программного стека виртуализации

В Fedora 44 процесс установки максимально упрощен благодаря группам пакетов. Нам не нужно собирать зависимости вручную; достаточно использовать мета-пакеты, которые подтянут всё необходимое: от самого эмулятора до инструментов управления.

Основные компоненты

Выполните команду установки:

sudo dnf install -y @virtualization

Символ @ указывает DNF, что нужно установить группу пакетов «Virtualization». В неё входят:

• qemu-kvm: Основной пакет, обеспечивающий аппаратное ускорение.
• libvirt: API и демон (libvirtd) для управления виртуализацией.
• virt-install: Утилита командной строки для создания новых VM.
• virt-viewer: Инструмент для графического подключения к консоли (через SPICE/VNC).
• libvirt-client: Набор клиентских утилит, включая virsh.

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

sudo dnf install -y virt-manager libguestfs-tools bridge-utils

• virt-manager: Хотя мы работаем удаленно, наличие этого GUI-инструмента полезно, если вы планируете использовать X11 Forwarding.
• libguestfs-tools: Мощнейший набор утилит для модификации образов дисков виртуальных машин без их запуска (например, virt-customize или virt-df).

Активация и настройка демона libvirtd

После установки пакетов система еще не готова к работе. Демон libvirtd, который является «мозгом» нашей инфраструктуры, по умолчанию может быть не запущен.

В современных дистрибутивах на базе Fedora/RHEL используется модульный подход к libvirtd. Вместо одного монолитного демона запускаются отдельные сервисы для управления сетями, хранилищами и интерфейсами. Однако для простоты администрирования на начальном этапе мы будем использовать основной сервис.

Активируем и запускаем службу:

sudo systemctl enable --now libvirtd

Проверьте статус службы, чтобы убедиться в отсутствии ошибок при инициализации модулей ядра:

systemctl status libvirtd

Если вы видите active (running), значит, KVM успешно подгрузил модули kvm_intel или kvm_amd. Вы можете подтвердить это командой:

lsmod | grep kvm

Разграничение прав доступа

Работа под учетной записью root — плохая практика. Для повседневного управления виртуальными машинами через SSH нам нужно настроить права доступа для обычного пользователя.

В Fedora группа libvirt обладает правами на управление гипервизором. Добавьте вашего текущего пользователя в эту группу:

sudo usermod -aG libvirt $(whoami)

Чтобы изменения вступили в силу без перезагрузки, выполните:

newgrp libvirt

Теперь вы можете выполнять команды управления (например, virsh list --all) без префикса sudo. Это не только вопрос безопасности, но и удобства: многие инструменты (например, Cockpit или графические клиенты) ожидают именно такого способа аутентификации.

Тонкая настройка конфигурации libvirt

Файл /etc/libvirt/libvirtd.conf содержит настройки демона. Для удаленного администрирования через SSH нам обычно не требуется менять настройки прослушивания портов (так как SSH обеспечивает туннелирование), но есть параметры, которые стоит проверить.

Особое внимание уделите механизмам блокировки дисков. Если в будущем вы планируете использовать общее хранилище для нескольких гипервизоров, вам понадобится virtlockd. В рамках одного сервера убедитесь, что лимиты на количество открытых файлов достаточно высоки, так как каждая виртуальная машина — это процесс QEMU, открывающий множество дескрипторов (образы дисков, логи, каналы связи).

Проверка готовности: virt-host-validate

Теперь, когда стек установлен и запущен, пришло время финальной проверки. Утилита virt-host-validate просканирует состояние хоста и укажет на возможные проблемы.

virt-host-validate

Типичный вывод должен содержать PASS по всем критическим пунктам:

• QEMU: Checking for hardware virtualization: PASS
• QEMU: Checking if device /dev/kvm exists: PASS
• QEMU: Checking if device /dev/vhost-net exists: PASS
• QEMU: Checking for device assignment IOMMU support: PASS (если вы включили IOMMU в GRUB)

Если вы видите WARN напротив IOMMU, это не критично для запуска VM, но ограничит вас в будущем при попытке пробросить физическую видеокарту или сетевой адаптер внутрь гостя. Если же FAIL стоит напротив /dev/kvm, значит, модули ядра не загружены — проверьте настройки BIOS еще раз.

Оптимизация производительности хоста

Гипервизор — это система, которая должна отдавать максимум ресурсов гостям. Fedora по умолчанию настроена как универсальная ОС, что не всегда оптимально для KVM.

Профили электропитания (tuned)

Установите и активируйте сервис tuned, который автоматически оптимизирует параметры ядра под конкретную задачу:

sudo dnf install -y tuned
sudo systemctl enable --now tuned

Для гипервизора оптимальным профилем является virtual-host. Он настраивает планировщик задач процессора и параметры кэширования так, чтобы минимизировать задержки (latency) при переключении контекста между виртуальными машинами.

sudo tuned-adm profile virtual-host

Проверить активный профиль можно командой tuned-adm active.

Настройка HugePages (введение)

Хотя детальная настройка памяти выходит за рамки первой главы, стоит упомянуть о HugePages. По умолчанию Linux использует страницы памяти размером 4 Кб. Для виртуальных машин с большим объемом RAM (от 16 Гб и выше) управление огромным количеством мелких страниц создает нагрузку на TLB (Translation Lookaside Buffer) процессора. Использование страниц по 2 Мб или 1 Гб значительно ускоряет работу с памятью. На этапе подготовки достаточно знать, что Fedora поддерживает это «из коробки», и мы вернемся к этому при конфигурировании тяжелых VM.

Безопасность: SELinux и Firewall

Fedora известна строгими политиками безопасности. SELinux в режиме Enforcing — это стандарт. Не отключайте его! KVM и Libvirt отлично интегрированы с SELinux через механизм sVirt.

sVirt: как это работает

Когда вы запускаете виртуальную машину, Libvirt динамически назначает процессу QEMU и файлу образа диска уникальную метку SELinux. Это гарантирует, что даже если злоумышленник «взломает» процесс QEMU изнутри виртуальной машины, он не сможет прочитать файлы другой VM или получить доступ к критическим файлам хоста, так как метки не совпадут.

Для проверки статуса выполните:

getenforce

Должно быть Enforcing. Если по какой-то причине вы видите Disabled, верните его в /etc/selinux/config и перезагрузитесь.

Настройка Firewalld

Для удаленного управления и работы сетевых мостов необходимо разрешить соответствующие сервисы в межсетевом экране.

sudo firewall-cmd --permanent --add-service=libvirt
sudo firewall-cmd --permanent --add-service=libvirt-rpc
sudo firewall-cmd --reload

Это позволит корректно работать протоколам управления. Если вы планируете использовать графический интерфейс Cockpit (который мы разберем в финале курса), добавьте и его:

sudo firewall-cmd --permanent --add-service=cockpit
sudo firewall-cmd --reload

Подготовка структуры каталогов

По умолчанию Libvirt хранит образы дисков в /var/lib/libvirt/images. Однако в реальных серверных сценариях под данные виртуальных машин часто выделяют отдельные дисковые массивы или разделы, смонтированные в другие точки.

Согласно нашему плану, мы будем использовать директорию /mnt/kvm-data. Создадим её заранее и установим правильные права доступа, чтобы Libvirt мог с ней работать:

sudo mkdir -p /mnt/kvm-data
sudo chown root:root /mnt/kvm-data
sudo chmod 755 /mnt/kvm-data

Важно помнить о контексте SELinux для нестандартных директорий. Если просто создать папку, Libvirt не сможет запустить в ней диск из-за запрета системы безопасности. Назначим правильный тип контекста:

sudo semanage fcontext -a -t virt_image_t "/mnt/kvm-data(/.*)?"
sudo restorecon -Rv /mnt/kvm-data

Здесь тип virt_image_t сообщает SELinux, что в данной директории разрешено хранить образы дисков виртуальных машин. Без этой настройки вы получите ошибку "Permission denied" при попытке запустить VM, даже если права доступа файловой системы (rwx) настроены верно.

Особенности Fedora 44: переход на cgroup v2

Fedora 44 полностью использует cgroup v2 для управления ресурсами. Для администратора KVM это означает более предсказуемое ограничение ресурсов (CPU, I/O, RAM) для каждой виртуальной машины. Libvirt автоматически создает иерархию в /sys/fs/cgroup/machine.slice.

Если вы планируете использовать скрипты для мониторинга ресурсов, которые были написаны для старых систем (например, CentOS 7), они могут перестать работать. В cgroup v2 все контроллеры (cpu, memory, io) находятся в одной иерархии, что упрощает управление, но требует обновления инструментария.

Первичная проверка сетевого стека

Хотя детальная настройка моста (bridge) на интерфейсе enp2s0 запланирована на следующую главу, сейчас важно убедиться, что в системе установлены компоненты для работы с сетью.

Проверьте наличие модуля vhost_net:

lsmod | grep vhost_net

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

Также убедитесь, что включен IP Forwarding, так как гипервизор по сути является маршрутизатором для своих виртуальных машин:

sysctl net.ipv4.ip_forward

Если значение равно 0, временно включите его (Libvirt обычно делает это сам при создании сетей, но лучше контролировать процесс):

sudo sysctl -w net.ipv4.ip_forward=1

Завершение этапа подготовки

На данный момент наш сервер на Fedora 44 полностью готов к работе в качестве гипервизора. Мы не просто установили пакеты, а подготовили почву:

1. Проверили и активировали аппаратную виртуализацию.
2. Оптимизировали ядро через параметры загрузки и профили tuned.
3. Настроили права доступа и безопасность через SELinux.
4. Создали структуру для хранения данных с учетом политик безопасности.

Впереди — настройка сетевой инфраструктуры. Нам предстоит превратить физический интерфейс enp2s0 в сетевой мост, который позволит виртуальным машинам стать полноправными участниками вашей локальной сети, получать IP-адреса по DHCP и быть доступными извне так же, как и физические серверы. Но прежде чем переходить к сетям, убедитесь, что команда virsh uri возвращает qemu:///system — это подтверждение того, что ваш клиент настроен на работу с системным гипервизором.

Настройка пулов хранения данных и сетевой инфраструктуры моста на интерфейсе enp2s0

Представьте, что вы построили мощный двигатель, но забыли подвести к нему топливные магистрали и построить дороги, по которым он будет перевозить грузы. В мире виртуализации «топливо» — это данные на дисках, а «дороги» — это сетевые интерфейсы. Без грамотно настроенного хранилища и сетевого моста ваш гипервизор KVM останется изолированным островом мощности, не способным ни сохранить состояние системы, ни ответить на запрос извне. В Fedora 44 управление этими ресурсами требует понимания того, как libvirt взаимодействует с подсистемами Linux: NetworkManager для сети и файловыми системами для хранения.

Архитектура хранения в libvirt: от директорий до логических томов

Прежде чем создавать виртуальные диски, необходимо определить, где и как они будут располагаться. В libvirt для этого используется концепция пулов хранения (Storage Pools). Пул — это логическое пространство, которое гипервизор резервирует для размещения образов дисков (Volumes).

Многие начинающие администраторы совершают ошибку, просто указывая путь к файлу ISO или диску в произвольной папке. Это работает до первого перезапуска или изменения политик SELinux. Правильный подход — регистрация пула, что позволяет libvirt управлять правами доступа, отслеживать свободное место и корректно выставлять контексты безопасности.

Подготовка физического уровня в /mnt/kvm-data

Мы будем использовать выделенную директорию /mnt/kvm-data. Это критически важно для изоляции данных виртуальных машин от системного раздела. Если гостевая ОС начнет неконтролируемо записывать логи и заполнит диск, упадет только пул данных, а не весь хост Fedora.

Для начала создадим структуру каталогов. Нам понадобятся два подраздела: один для образов дисков (основные данные), другой для ISO-образов (установочные носители).

sudo mkdir -p /mnt/kvm-data/{images,iso}

Теперь необходимо убедиться, что владелец и права доступа позволяют демону virtqemud (или libvirtd в классической конфигурации) работать с этими файлами. В Fedora 44 процессы QEMU обычно запускаются от имени пользователя qemu.

sudo chown -R qemu:qemu /mnt/kvm-data
sudo chmod -R 770 /mnt/kvm-data

Определение и активация пула через virsh

Утилита virsh — это ваш основной скальпель. Создание пула проходит в три этапа: определение (define), сборка (build) и запуск (start).

1. Определение конфигурации: Мы создаем XML-описание пула. Но вместо ручного редактирования XML воспользуемся командой pool-define-as.

   sudo virsh pool-define-as --name vms-images --type dir --target /mnt/kvm-data/images
   

   Здесь --name — это произвольное имя пула в консоли управления, --type dir указывает на использование обычной файловой системы, а --target — путь на хосте.

2. Инициализация: Если директория уже существует, этот шаг формален, но он необходим для синхронизации метаданных libvirt.

   sudo virsh pool-build vms-images
   

3. Запуск и автозапуск: Чтобы пул был доступен после перезагрузки сервера, его нужно активировать и пометить флагом autostart.

   sudo virsh pool-start vms-images
   sudo virsh pool-autostart vms-images
   

Повторите эти действия для пула ISO-образов, назвав его, например, vms-iso. Это позволит вам удобно выбирать дистрибутивы при создании машин через virt-install или Cockpit.

Нюансы SELinux и пулов хранения

Fedora славится своей строгой политикой безопасности. Если вы просто создадите папку, SELinux заблокирует доступ QEMU к ней, даже если права доступа Linux ($777$) будут открыты. Мы уже касались этого в первой главе, но при создании новых пулов важно помнить о рекурсивном применении контекста.

Контекст virt_image_t сообщает ядру, что файлы в данной директории могут быть прочитаны и записаны процессами виртуализации. Без этого вы получите ошибку "Permission denied" при попытке запустить VM.

Проверьте текущий статус:

ls -Zd /mnt/kvm-data/images

Если вы видите что-то отличное от virt_image_t, примените правила:

sudo semanage fcontext -a -t virt_image_t "/mnt/kvm-data(/.*)?"
sudo restorecon -R -v /mnt/kvm-data

Сетевая инфраструктура: переход от NAT к Bridge

По умолчанию libvirt создает виртуальную сеть default с использованием NAT (Network Address Translation). Это удобно для быстрого старта: машина получает доступ в интернет, но она «спрятана» за IP-адресом хоста. Для системного администратора это часто является ограничением. Если вы хотите, чтобы виртуальный сервер был полноценным участником локальной сети (например, получал IP от корпоративного DHCP-сервера или был доступен по SSH напрямую), вам необходим сетевой мост (Bridge).

Почему именно Bridge на enp2s0?

Сетевой мост работает на втором уровне модели OSI (Data Link). Представьте его как виртуальный коммутатор (L2-switch), встроенный в ваш сервер. Один порт этого коммутатора «смотрит» на физическую сетевую карту enp2s0, а другие порты динамически создаются для каждой виртуальной машины.

Преимущества моста:

• Прямая видимость VM в локальной сети.
• Отсутствие задержек и нагрузки на процессор, связанных с трансляцией адресов (NAT).
• Возможность использования специфических протоколов (PXE-загрузка, мультикаст), которые плохо проходят через NAT.

Настройка моста через NetworkManager (nmcli)

В Fedora 44 управление сетью осуществляется через NetworkManager. Мы не будем вручную править файлы в /etc/sysconfig/network-scripts, так как этот подход считается устаревшим. Вместо этого воспользуемся мощной утилитой nmcli.

Внимание: Выполнение этих команд удаленно по SSH сопряжено с риском потери связи. Убедитесь, что у вас есть доступ к консоли сервера (IPMI/iDRAC) или вы точно следуете инструкциям.

1. Создание интерфейса моста: Создаем логический интерфейс br0.

   sudo nmcli connection add type bridge autoconnect yes con-name br0 ifname br0
   

2. Привязка физического интерфейса к мосту: Теперь мы делаем enp2s0 «рабом» (slave) нашего моста. С этого момента физическая карта перестает иметь собственный IP-адрес и начинает работать как транзитный порт.

   sudo nmcli connection add type bridge-slave autoconnect yes con-name br0-slave ifname enp2s0 master br0
   

3. Настройка IP на мосту: Теперь адрес должен принадлежать интерфейсу br0. Если в вашей сети работает DHCP:

   sudo nmcli connection modify br0 ipv4.method auto
   

   Если же серверу нужен статический адрес (что предпочтительнее для гипервизора):

   sudo nmcli connection modify br0 ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8,8.8.4.4" ipv4.method manual
   

4. Активация изменений: Это самый опасный момент. Нам нужно отключить старое соединение на enp2s0 и включить мост.

   sudo nmcli connection up br0
   

   Обычно NetworkManager автоматически подтянет slave-интерфейс. Проверьте статус командой ip addr show. Вы должны увидеть, что у enp2s0 нет IP-адреса, а у br0 — есть.

Интеграция моста в libvirt

Создание моста в системе — это только половина дела. Теперь нужно объяснить libvirt, что он может использовать этот мост для подключения виртуальных машин. Для этого создается описание сетевого ресурса в формате XML.

Создайте файл bridge.xml:

<network>
  <name>host-bridge</name>
  <forward mode="bridge"/>
  <bridge name="br0"/>
</network>

Теперь зарегистрируйте эту сеть в гипервизоре:

sudo virsh net-define bridge.xml
sudo virsh net-start host-bridge
sudo virsh net-autostart host-bridge

Проверьте результат: sudo virsh net-list --all. Теперь при создании VM вы сможете указать сеть host-bridge, и машина окажется в одном сегменте с вашим физическим сервером.

Фильтрация трафика и Netfilter

При работе с мостами в Linux возникает важный нюанс: по умолчанию трафик, проходящий через мост, обрабатывается правилами iptables/nftables хоста. Это может привести к тому, что firewalld на Fedora будет блокировать пакеты, предназначенные для виртуальных машин.

Для корректной работы часто требуется отключить обработку мостового трафика в netfilter. Это делается через параметры ядра (sysctl):

sudo tee /etc/sysctl.d/99-kvm-bridge.conf <<EOF
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-arptables = 0
EOF
sudo sysctl --system

Однако, если вы планируете использовать продвинутые функции фильтрации трафика средствами libvirt (nwfilter), эти параметры могут потребоваться включенными. Для стандартного администрирования на среднем уровне их отключение избавляет от множества проблем с недоступностью портов внутри VM.

Оптимизация производительности хранилища

Просто создать пул в директории — достаточно для обучения, но недостаточно для высоконагруженного сервера. В Fedora 44 по умолчанию используется файловая система XFS или Btrfs. Если ваш /mnt/kvm-data находится на Btrfs, вы можете столкнуться с деградацией производительности из-за механизма CoW (Copy-on-Write).

При записи данных в файл образа диска (особенно формата qcow2) Btrfs будет пытаться создавать новые фрагменты данных, что приведет к колоссальной фрагментации файла.

Рекомендация: Если вы используете Btrfs для пула хранения, отключите CoW для директории с образами сразу после её создания:

sudo chattr +C /mnt/kvm-data/images

Атрибут +C гарантирует, что новые файлы в этой папке не будут использовать Copy-on-Write, что критично для производительности баз данных и системных дисков внутри VM.

Выбор формата образа: Raw vs QCOW2

Внутри созданного пула вы будете оперировать томами. У вас есть два основных выбора:

1. Raw: Максимальная производительность. Это просто двоичный файл, представляющий собой «слепок» диска.

   • Плюсы: Минимум накладных расходов.
   • Минусы: Занимает всё выделенное место сразу (если не использовать разреженные файлы), не поддерживает снимки (snapshots) средствами самого файла.

2. QCOW2 (QEMU Copy On Write): Стандарт де-факто для KVM.

   • Плюсы: Поддержка снимков, сжатие, шифрование и «тонкое» выделение места (файл растет по мере заполнения данными внутри VM).
   • Минусы: Незначительная потеря производительности на операциях записи из-за метаданных.

Для большинства задач в курсе мы будем использовать qcow2, так как гибкость управления (особенно создание снимков, которое мы разберем в главе 8) перевешивает небольшую потерю в скорости.

Тонкая настройка сетевых интерфейсов гостя

Когда мы говорим о сетевом мосте, важно понимать, как именно гость «видит» сеть. В KVM за это отвечает модель виртуального сетевого адаптера.

Существует два основных подхода:

• Эмуляция (e1000, rtl8139): Гипервизор имитирует работу реального «железного» адаптера Intel или Realtek. Это медленно, так как каждый пакет вызывает прерывание и переключение контекста процессора.
• VirtIO-net: Паравиртуализированный драйвер. Гостевая ОС «знает», что она работает в виртуальной среде, и обменивается данными с гипервизором через общую память.

$$Производительность \approx \frac{Bandwidth}{Latency}$$

Использование virtio-net минимизирует Latency (задержку) и позволяет достигать скоростей передачи данных, близких к физической пропускной способности интерфейса $10$ Гбит/с и выше, даже на стандартном оборудовании. В Fedora 44 и большинстве современных Linux-дистрибутивов драйверы virtio встроены в ядро, поэтому всегда выбирайте этот тип интерфейса при настройке сети.

Управление через virsh: полезные команды для пулов и сетей

Для уверенного администрирования вам необходимо знать состояние ваших ресурсов в любой момент.

Мониторинг хранилища:

• virsh pool-info vms-images — покажет общий объем, используемое и свободное место в пуле.
• virsh vol-list vms-images — выведет список всех виртуальных дисков в пуле с указанием их путей.
• virsh vol-capacity /путь/к/образу — поможет узнать реальный и логический размер конкретного диска.

Мониторинг сети:

• virsh net-info host-bridge — статус виртуальной сети.
• virsh net-dhcp-leases host-bridge — если бы мы использовали встроенный DHCP libvirt, эта команда показала бы выданные IP-адреса. В случае с мостом на br0 адреса нужно смотреть на вашем внешнем DHCP-сервере или внутри VM.

Расширение пула «на лету»

Если вы добавили новый физический диск в сервер и расширили раздел /mnt/kvm-data средствами LVM или файловой системы, libvirt может не сразу заметить изменения. Чтобы обновить информацию о свободном месте в пуле без перезагрузки:

sudo virsh pool-refresh vms-images

Эта команда заставляет демон пересканировать целевую директорию и обновить метаданные о доступной емкости.

Изоляция и безопасность: использование нескольких мостов

В продвинутых сценариях администрирования часто требуется разделить трафик управления (Management), трафик данных и публичный трафик. Для этого на сервере создается несколько мостов. Например, br0 может быть привязан к enp2s0 для внешней сети, а br1 — к enp3s0 для внутренней изолированной сети между виртуальными машинами.

В Fedora 44 вы можете создавать «пустые» мосты (без физических интерфейсов) для создания изолированных сегментов (Private Cloud). Виртуальные машины внутри такого моста смогут общаться друг с другом, но не будут иметь выхода во внешнюю сеть хоста, если вы не настроите маршрутизацию вручную. Это идеальный полигон для тестирования кластерных решений или сетевых экранов.

Настройка сетевой и дисковой подсистем — это фундамент. Мы создали надежное хранилище в /mnt/kvm-data, защитили его контекстами SELinux, оптимизировали файловую систему и построили скоростную магистраль в виде сетевого моста br0. Теперь ваш сервер Fedora 44 готов к тому, чтобы принять на борт первую виртуальную машину, обеспечив ей производительность, сравнимую с физическим оборудованием.

Создание виртуальной машины: определение аппаратной конфигурации и ресурсов

Представьте, что вы проектируете серверную стойку, где каждый миллиметр пространства и каждый ватт энергии должны быть строго учтены. В мире виртуализации роль этой стойки выполняет конфигурационный файл виртуальной машины (VM). Ошибка на этапе выделения ресурсов — например, избыточное резервирование оперативной памяти или неверный выбор модели процессора — может привести к «эффекту домино»: одна прожорливая машина замедлит работу всего гипервизора, вызвав деградацию производительности соседних сервисов. В Fedora 44 процесс создания VM требует не просто запуска команды, а глубокого понимания того, как абстрактные цифры в конфигурации превращаются в реальные циклы процессора и блоки данных на диске.

Архитектура ресурсов: баланс между физикой и виртуальностью

Прежде чем выполнить первую команду virt-install, необходимо определить «профиль» будущей системы. В нашем сценарии мы ориентируемся на стандартную нагрузку: 2 ядра CPU и 4 Гб RAM. Однако эти цифры — лишь верхушка айсберга. В KVM распределение ресурсов происходит через уровни абстракции, которыми управляет QEMU под контролем libvirt.

Процессорные ресурсы и топология

Когда мы выделяем 2 ядра, мы должны решить, как они будут представлены гостевой операционной системе. Существует три основных подхода к определению модели CPU:

1. Custom (Индивидуальный): Вы указываете конкретную модель (например, Haswell или EPYC). Это гарантирует, что VM запустится на другом хосте с похожим или более новым процессором, что критично для живой миграции.
2. Host-model: Libvirt анализирует возможности физического процессора хоста и подбирает максимально близкую конфигурацию, отсекая те инструкции, которые могут вызвать нестабильность. Это «золотая середина».
3. Host-passthrough: Гостевая система видит процессор в точности так, как его видит хост (включая все специфические флаги, такие как AES-NI или AVX-512). Это обеспечивает максимальную производительность, но делает невозможной миграцию на сервер с другим типом CPU.

Для администратора Fedora 44 наиболее предпочтительным является режим host-model, так как он обеспечивает отличную производительность при сохранении гибкости управления.

Оперативная память и механизмы оптимизации

Выделение 4 Гб RAM кажется простой задачей, но в KVM существует понятие «раздувания» (ballooning). Драйвер virtio-balloon позволяет гипервизору динамически забирать неиспользуемую память у гостевой системы и отдавать её другим процессам хоста.

Однако стоит учитывать нюанс: если вы выделяете 4 Гб, Fedora зарезервирует этот объем в адресном пространстве процесса QEMU. Если на хосте включен KSM (Kernel Same-page Merging), одинаковые страницы памяти разных VM будут объединены, что сэкономит физическую RAM. Но для высоконагруженных баз данных это может создать задержки, поэтому в таких случаях лучше использовать стационарное выделение без переподписки (overcommit).

Инструментарий virt-install: препарируем команду

Утилита virt-install является основным инструментом командной строки для создания VM. Она генерирует XML-описание (domain XML) и инициирует процесс установки. Рассмотрим детально синтаксис, который позволит нам развернуть машину с заданными параметрами.

Разбор ключевых флагов

Для создания нашей целевой машины мы будем использовать следующую конструкцию:

virt-install \
  --name fedora-server-01 \
  --vcpus 2 \
  --memory 4096 \
  --os-variant fedora-unknown \
  --disk pool=vms-images,size=20,format=qcow2,bus=virtio \
  --network bridge=br0,model=virtio \
  --graphics spice,listen=0.0.0.0 \
  --controller type=usb,model=q35-ehci \
  --machine q35 \
  --boot hd,cdrom \
  --cdrom /mnt/kvm-data/iso/Fedora-Server-dvd-x86_64-44.iso

Проанализируем каждый параметр с точки зрения системного администрирования:

• --name: Уникальный идентификатор VM в рамках данного гипервизора. Используйте осмысленные имена, так как они станут именами файлов логов и конфигураций.
• --vcpus 2: Количество виртуальных процессоров. По умолчанию они распределяются планировщиком хоста.
• --memory 4096: Объем оперативной памяти в мегабайтах.
• --os-variant: Критически важный параметр. Он сообщает virt-install, какие оптимизации применить. Для Fedora 44 можно использовать fedora-unknown или актуальное значение из списка osinfo-query os. Это автоматически настраивает рекомендуемые типы устройств (например, VirtIO).
• --disk: Здесь мы указываем созданный ранее пул vms-images. Параметр bus=virtio обязателен для производительности, так как он задействует паравиртуализированный драйвер диска, минуя медленную эмуляцию IDE/SATA.
• --network bridge=br0: Мы подключаем машину к нашему мосту на интерфейсе enp2s0. Использование model=virtio обеспечивает пропускную способность сети, близкую к физической.
• --graphics spice: Настройка протокола удаленного доступа, который мы подробно разберем в следующей главе.
• --machine q35: Использование современной архитектуры чипсета (Q35) вместо устаревшей i440FX. Q35 поддерживает PCIe, более эффективное управление прерываниями и современную топологию шин.

Глубокая настройка: CPU Pinning и топология

Для системных администраторов среднего уровня простого выделения «2 ядер» может быть недостаточно. Важно понимать, как эти ядра соотносятся с физическими потоками (threads) и ядрами процессора хоста.

Зачем нужно закрепление ядер (Pinning)?

В стандартной конфигурации планировщик Linux может перемещать процессы QEMU между любыми свободными ядрами хоста. Это приводит к очистке кэшей процессора (L1/L2) и снижению производительности. Если ваша VM выполняет критические задачи, стоит рассмотреть vcpupin.

Предположим, наш сервер имеет 8 ядер. Мы можем жестко привязать vCPU 0 к физическому ядру 2, а vCPU 1 — к физическому ядру 3. Это делается через редактирование XML-конфигурации (virsh edit):

<vcpu placement='static'>2</vcpu>
<cputune>
    <vcpupin vcpu='0' cpuset='2'/>
    <vcpupin vcpu='1' cpuset='3'/>
</cputune>

Такой подход минимизирует «дрожание» (jitter) и обеспечивает предсказуемое время отклика гостевой системы.

Настройка топологии (Sockets, Cores, Threads)

Гостевая ОС должна понимать структуру выделенных ресурсов. Для 2 ядер мы можем представить их как:

1. 1 сокет с 2 ядрами (наиболее частый вариант).
2. 2 сокета по 1 ядру (может потребоваться для обхода лицензионных ограничений ПО, которое лицензируется по сокетам).
3. 1 сокет, 1 ядро, 2 потока (имитация Hyper-Threading).

В virt-install это задается параметром --vcpus 2,sockets=1,cores=2,threads=1. Правильная топология важна для корректной работы планировщика внутри гостевой ОС, особенно в многоядерных системах.

Эмуляция чипсета и системные устройства

Выбор типа машины --machine q35 в Fedora 44 является стандартом де-факто. В отличие от старого pc (i440FX), чипсет Q35 предоставляет:

• Поддержку безопасной загрузки (Secure Boot) через UEFI.
• Нативную поддержку шины PCI Express.
• Более эффективную работу с устройствами ввода-вывода.

При создании VM важно также обратить внимание на контроллеры. Например, использование virtio-scsi вместо стандартного virtio-blk дает больше возможностей, таких как поддержка команды TRIM (важно для SSD на хосте) и подключение большего количества дисков к одному контроллеру.

Контроллеры памяти и Ballooning

Для эффективного управления 4 Гб памяти в конфигурации должно присутствовать устройство memballoon. Оно создается автоматически при использовании virt-install, но администратор должен знать, как им управлять.

Если гостевой системе внезапно требуется больше памяти, а на хосте её мало, драйвер balloon внутри VM «раздувается», заставляя гостевую ОС сбросить кэши и освободить страницы, которые затем перехватываются гипервизором. Без установленных драйверов внутри гостя (о которых мы поговорим в главе об оптимизации) этот механизм работать не будет.

Подготовка к первому запуску: нюансы UEFI и BIOS

По умолчанию многие VM создаются с использованием традиционного BIOS (SeaBIOS). Однако для современных дистрибутивов, включая Fedora, предпочтительнее использовать UEFI (через проект OVMF).

Для активации UEFI в virt-install необходимо добавить флаг --boot uefi. Это создаст переменную часть NVRAM для хранения настроек загрузчика. В Fedora 44 пакет edk2-ovmf должен быть установлен на хосте заранее. Использование UEFI позволяет:

• Работать с дисками объемом более 2 Тб (таблица разделов GPT).
• Ускорить процесс инициализации системы.
• Использовать современные графические драйверы на ранних этапах загрузки.

Проектирование дисковой подсистемы в /mnt/kvm-data

Мы уже определили, что будем использовать пул в /mnt/kvm-data. При создании VM объемом 20 Гб важно понимать разницу в аллокации пространства.

Тонкое выделение (Sparse files)

Формат QCOW2 поддерживает «тонкие» диски. Это означает, что файл образа на диске хоста будет занимать ровно столько места, сколько данных записано внутри VM. Команда: --disk pool=vms-images,size=20,format=qcow2 создаст файл, который изначально может весить всего несколько сотен килобайт.

Опасность: Если вы создадите десять VM по 20 Гб на диске объемом 100 Гб, и все они начнут активно записывать данные, место на хосте закончится внезапно. Это называется «overprovisioning». Системный администратор обязан отслеживать реальное заполнение физического раздела /mnt/kvm-data.

Кэширование дисковых операций

Параметр cache в определении диска критически влияет на сохранность данных и скорость.

• none: Данные пишутся напрямую, минуя кэш хоста. Самый безопасный и рекомендуемый вариант для производительных систем.
• writethrough: Кэш на чтение активен, но запись подтверждается только после фиксации на физическом носителе.
• writeback: Высокая скорость, так как запись подтверждается сразу после попадания в кэш хоста. Риск потери данных при сбое питания сервера.

Для нашей учебной VM мы будем придерживаться настроек по умолчанию, которые virt-install выбирает как наиболее сбалансированные для Fedora.

Сетевая конфигурация: мост против NAT

Хотя libvirt часто предлагает сеть default (NAT), в профессиональной среде системные администраторы используют мосты.

Когда мы указываем --network bridge=br0, виртуальная машина становится полноправным участником локальной сети. Её трафик проходит через интерфейс enp2s0 без трансляции адресов. Это позволяет:

1. Получать IP-адрес напрямую от DHCP-сервера вашей организации.
2. Обеспечивать доступ к VM по SSH без проброса портов.
3. Минимизировать нагрузку на процессор хоста, связанную с обработкой NAT-таблиц.

Важно убедиться, что на хосте Fedora 44 правила firewalld позволяют прохождение трафика через мост. Обычно это требует добавления интерфейса моста в доверенную зону или настройки специфических правил forward.

Финализация конфигурации перед установкой

После запуска virt-install процесс перейдет в стадию ожидания подключения к консоли или графическому интерфейсу. Но работа администратора на этом не заканчивается. Сразу после создания описания полезно проверить итоговый XML-файл:

virsh dumpxml fedora-server-01

В этом выводе вы увидите полную картину: какие PCI-адреса были назначены устройствам, как распределены прерывания и какие эмулируемые устройства (например, звуковые карты или контроллеры USB) были добавлены автоматически. Лишние устройства (например, неиспользуемый флоппи-дисковод или звуковой контроллер в серверной VM) рекомендуется удалять для уменьшения поверхности атаки и экономии ресурсов.

Пример оптимизации XML

Если вы обнаружили в конфигурации лишние элементы, их можно убрать через virsh edit. Например, удаление видеокарты vga и замена её на virtio значительно улучшит отзывчивость графического интерфейса, если он используется. Однако для чисто серверной установки часто оставляют минимальный video model='vga' для совместимости.

Определение аппаратной конфигурации — это процесс поиска компромисса. 2 ядра и 4 Гб оперативной памяти — это наш фундамент. Правильный выбор чипсета Q35, использование драйверов VirtIO и настройка сетевого моста превращают этот фундамент в надежную платформу, готовую к установке операционной системы. Понимание того, как каждый флаг в virt-install влияет на итоговый XML-файл, отличает простого пользователя от системного администратора, способного эксплуатировать KVM в промышленной среде.

Установка операционной системы и настройка удаленного доступа по протоколу SPICE

Представьте, что вы запустили процесс установки операционной системы на удаленном сервере, находящемся в другом дата-центре. Внезапно инсталлятор запрашивает подтверждение разметки диска, но SSH-сессия не дает доступа к графическому интерфейсу, а текстовый режим (VNC) безбожно тормозит или искажает цвета. В мире профессиональной виртуализации KVM решение этой проблемы кроется в протоколе SPICE. Он превращает работу с удаленной виртуальной машиной в опыт, практически неотличимый от локального использования: с плавной графикой, общим буфером обмена и пробросом звука. Однако, чтобы этот механизм заработал, необходимо правильно инициировать процесс установки ОС и сконфигурировать параметры отображения еще на этапе старта домена.

Запуск процесса установки через virt-install

На предыдущих этапах мы подготовили аппаратную конфигурацию и ресурсы. Теперь наступает критический момент — связывание ISO-образа с виртуальным приводом и запуск первичной загрузки. Для администратора, работающего через SSH, важно понимать, что virt-install — это не просто скрипт, а мощный инструмент формирования XML-описания домена, который сразу после создания отправляет машину в состояние running.

При установке Fedora или RHEL-подобных систем на KVM, мы используем флаг --location или --cdrom. Разница между ними существенна. Использование --cdrom просто подключает образ как виртуальный диск, тогда как --location позволяет передавать дополнительные параметры ядру инсталлятора (kernel arguments), что полезно для автоматизации через Kickstart.

Рассмотрим расширенную команду запуска для нашей конфигурации:

virt-install \
  --name fedora-srv-01 \
  --vcpus 2 \
  --memory 4096 \
  --os-variant fedora-unknown \
  --disk path=/mnt/kvm-data/images/fedora-srv-01.qcow2,size=20,format=qcow2,bus=virtio,cache=none \
  --network bridge=br0,model=virtio \
  --graphics spice,listen=127.0.0.1 \
  --video qxl \
  --channel spicevmc,target_type=virtio,name=com.redhat.spice.0 \
  --console pty,target_type=serial \
  --cdrom /mnt/kvm-data/iso/Fedora-Server-dvd-x86_64-44.iso \
  --boot hd,cdrom,menu=on \
  --noautoconsole

В этой команде мы закладываем фундамент для работы SPICE. Флаг --graphics spice,listen=127.0.0.1 указывает гипервизору, что вывод графики должен осуществляться через протокол SPICE, но из соображений безопасности порт будет открыт только на локальном интерфейсе сервера (localhost). Это стандартная практика: мы не выставляем порты виртуализации напрямую в интернет, а используем SSH-туннелирование или VPN.

Архитектура протокола SPICE и видеоадаптер QXL

Для понимания того, почему мы выбрали именно такие параметры, необходимо разобрать внутреннее устройство взаимодействия гостя и хоста. В отличие от старого протокола VNC, который просто передает «снимки» экрана (фреймбуфер), SPICE (Simple Protocol for Independent Computing Environments) является адаптивным.

Роль драйвера QXL

Параметр --video qxl подключает к виртуальной машине специализированный видеоадаптер. QXL — это паравиртуальный драйвер, который понимает команды отрисовки 2D-графики. Когда гостевая ОС хочет нарисовать окно, она не отрисовывает его попиксельно в своей памяти, а передает высокоуровневые команды драйверу QXL. Эти команды по протоколу SPICE улетают на клиент (ваш компьютер), и уже ваша видеокарта занимается финальной отрисовкой. Это радикально снижает нагрузку на CPU сервера и требования к пропускной способности сети.

Коммуникационный канал spicevmc

Обратите внимание на строку --channel spicevmc,target_type=virtio,name=com.redhat.spice.0. Это создание «магистрали» для обмена данными между хостом и гостем, которая не относится к видеопотоку. Через этот канал будут передаваться:

1. События мыши: абсолютные координаты курсора (чтобы избежать «эффекта двух мышей», когда курсор гостя отстает от системного).
2. Буфер обмена: возможность копировать текст из вашей консоли в терминал внутри VM.
3. Разрешение экрана: автоматическая подстройка размера рабочего стола гостя под размер окна клиента.

Без этого канала SPICE будет работать лишь как «улучшенный VNC», лишая вас большинства удобств.

Удаленное подключение через SSH-туннель

Поскольку мы ограничили прослушивание порта SPICE адресом 127.0.0.1, прямое подключение к серверу по IP не удастся. Порты SPICE обычно начинаются с $5900$. Первая запущенная машина займет $5900$, вторая — $5901$ и так далее.

Чтобы увидеть экран установки на своей локальной машине (например, на вашем ноутбуке с Fedora или Windows), необходимо пробросить порт:

ssh -L 5900:127.0.0.1:5900 user@your-fedora-server

После этого на локальной машине вы запускаете клиент virt-viewer (в Windows он входит в состав пакета virt-viewer msi, в Linux — sudo dnf install virt-viewer):

remote-viewer spice://127.0.0.1:5900

Теперь перед вами откроется графическое окно инсталлятора Fedora. Благодаря драйверу VirtIO для диска и сети, который мы указали в virt-install, инсталлятор сразу увидит накопитель и сможет настроить сеть через мост br0.

Тонкости процесса установки ОС

При установке системы в виртуальной среде KVM есть несколько «подводных камней», игнорирование которых приведет к деградации производительности в будущем.

Разметка диска и выравнивание секторов

Хотя современные инсталляторы (Anaconda в Fedora) автоматически выравнивают разделы по границе 1 Мб, при ручной разметке важно следить, чтобы начало разделов совпадало с физическими блоками на хосте. В случае использования QCOW2 на файловой системе Btrfs (дефолт для Fedora 44), несоответствие границ блоков может вызвать эффект «double write», когда запись одного блока гостя инициирует перезапись двух блоков хоста.

Выбор программного обеспечения

На этапе выбора групп пакетов (Software Selection) для серверной ОС крайне рекомендуется выбирать «Minimal Install» или «Standard System Utilities». Лишние графические оболочки внутри сервера лишь потребляют ресурсы RAM, которые в виртуализации всегда в дефиците. Однако, есть один пакет, который обязателен к установке прямо сейчас — qemu-guest-agent. Если инсталлятор позволяет выбрать его в аддонах, сделайте это. Если нет — мы установим его сразу после первой загрузки.

Настройка консольного доступа через Serial PTY

Профессиональный администратор никогда не полагается только на графику. Если графическая подсистема SPICE «упадет» или возникнут проблемы с X-сервером внутри гостя, вам понадобится текстовый доступ. Для этого мы добавили --console pty,target_type=serial.

Внутри гостевой ОС (после установки) необходимо убедиться, что системная консоль выводится в последовательный порт. В Fedora это делается автоматически, но если вы устанавливаете другой дистрибутив, проверьте параметры загрузки ядра в /etc/default/grub. Там должна быть строка: console=tty0 console=ttyS0,115200n8

Это позволит вам подключаться к машине командой:

virsh console fedora-srv-01

Это «спасательный круг», работающий даже тогда, когда сеть внутри VM не настроена или заблокирована файерволом.

Оптимизация SPICE: Безопасность и пароли

В промышленной эксплуатации оставлять порт SPICE без пароля — плохая идея, даже если он слушает только localhost. Если на сервере работает несколько администраторов, любой из них сможет подключиться к вашей консоли.

Чтобы добавить пароль к уже созданной машине, необходимо отредактировать её XML-конфигурацию:

virsh edit fedora-srv-01

Найдите секцию <graphics> и приведите её к виду:

<graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1' passwd='YourStrongPassword'>
  <listen type='address' address='127.0.0.1'/>
  <image compression='off'/>
</graphics>

Параметр image compression='off' рекомендуется для локальных сетей или SSH-туннелей, так как современные CPU быстрее передают несжатые данные, чем тратят циклы на упаковку/распаковку потока, что снижает задержки (latency).

Взаимодействие с гостевой системой после установки

Когда установка завершена и машина ушла в перезагрузку, virt-install завершит свою работу. Теперь управление переходит к virsh.

Первым делом проверьте статус:

virsh list --all

Если машина выключена (что часто бывает после завершения инсталляции), запустите её:

virsh start fedora-srv-01

Настройка автоматического изменения разрешения

Чтобы разрешение экрана внутри remote-viewer менялось при растягивании окна, в гостевой системе должен быть запущен демон spice-vdagent.

1. Подключитесь к VM через SPICE.
2. Установите агент: sudo dnf install spice-vdagent.
3. Запустите и добавьте в автозагрузку:

   sudo systemctl enable --now spice-vdagentd
   

После этого гостевая ОС начнет получать данные о размере окна клиента через тот самый канал spicevmc, который мы создали ранее.

Сравнение SPICE и VNC в контексте администрирования

Часто возникает вопрос: почему не использовать старый добрый VNC? Приведем сравнение в таблице для понимания операционной эффективности.

Характеристика	VNC (Virtual Network Computing)	SPICE (Simple Protocol for Independent Computing Environments)
Передача графики	Растровые фреймбуферы (пиксели)	Высокоуровневые команды 2D (QXL)
Курсор мыши	Относительные координаты (возможен лаг)	Абсолютные координаты (VirtIO Input)
Буфер обмена	Требует сложной настройки сторонних утилит	Нативная поддержка (через spice-vdagent)
Звук	Отсутствует	Поддержка двусторонней передачи звука
Нагрузка на CPU хоста	Высокая (сжатие видеопотока)	Низкая (обработка команд)
Многомониторность	Ограничена	Поддержка до 4 мониторов на одну VM

Для системного администратора Fedora 44 выбор SPICE очевиден, так как весь стек (QEMU, libvirt, virt-viewer) оптимизирован именно под этот протокол. VNC остается лишь как легаси-вариант для очень старых ОС, которые не поддерживают драйверы QXL.

Нюансы работы с портами и брандмауэром

Хотя мы используем туннели, полезно знать, как Fedora управляет портами динамически. Libvirt по умолчанию выделяет порты из диапазона $5900-5999$. Если вы планируете запускать десятки машин и использовать Cockpit (который мы разберем позже), убедитесь, что firewalld на хосте не блокирует внутренние взаимодействия.

Для проверки того, какой именно порт заняла ваша машина:

virsh domdisplay fedora-srv-01

Команда вернет строку вида spice://127.0.0.1:5900, что подтверждает корректность настроек.

Использование нескольких каналов данных

В продвинутых конфигурациях через SPICE можно пробрасывать даже USB-устройства (например, токен с ключами ЭЦП). Для этого в конфигурацию добавляются контроллеры usb-redir. Хотя детально проброс USB мы изучим в главе 7, важно понимать, что фундамент закладывается именно сейчас. Если вы не укажете правильный тип шины (USB 2.0/3.0) в секции <devices>, SPICE-клиент не сможет «протолкнуть» устройство в гостя.

Для базовой установки достаточно стандартного набора, но всегда проверяйте наличие контроллера USB в XML:

<controller type='usb' index='0' model='ich9-ehci1'/>

Это обеспечит совместимость с большинством современных периферийных устройств, которые могут понадобиться в процессе настройки ОС.

Завершение этапа установки

После того как ОС установлена, агент запущен, а доступ по SPICE стабилен, ваша виртуальная машина готова к эксплуатации. Однако она все еще остается «черным ящиком» для гипервизора. Гипервизор знает, сколько памяти он выделил, но не знает, сколько памяти гость реально использует. Он видит нагрузку на CPU, но не знает имен процессов внутри. Чтобы стереть эту границу, следующим шагом станет глубокая интеграция через qemu-guest-agent, который позволит нам выполнять команды внутри VM прямо из консоли хоста и корректно «замораживать» файловую систему для создания консистентных снимков.

Работа с графикой через SPICE на этапе установки — это лишь верхушка айсберга. Главное преимущество этого протокола в том, что он позволяет администратору чувствовать систему, даже если она находится за тысячи километров, обеспечивая ту степень контроля, которая необходима для оперативного решения проблем в промышленной среде.

Оптимизация гостевой системы и интеграция через qemu-guest-agent

С точки зрения гипервизора виртуальная машина по умолчанию представляет собой «черный ящик». Хост выделяет процессорное время, страницы оперативной памяти и дисковое пространство, но совершенно не понимает, что именно происходит внутри гостевой операционной системы. Когда администратор отправляет команду на выключение, гипервизор может лишь сымитировать нажатие аппаратной кнопки питания или жестко прервать процесс QEMU. Если требуется узнать IP-адрес машины, хосту приходится анализировать сетевой трафик или опрашивать локальный DHCP-сервер. Чтобы преодолеть этот барьер изоляции и превратить виртуальную машину из непрозрачного набора ресурсов в управляемый компонент инфраструктуры, используется qemu-guest-agent.

Архитектура канала связи virtio-serial

Для взаимодействия между хостом и агентом внутри гостевой системы не используется классическая сеть (TCP/IP). Зависимость от сетевого стека сделала бы управление невозможным при ошибках маршрутизации, падении интерфейсов или строгих правилах брандмауэра. Вместо этого применяется паравиртуализованный последовательный канал virtio-serial.

На стороне хоста libvirt создает UNIX-сокет. На стороне гостевой системы этот сокет проецируется как символьное устройство, обычно доступное по пути /dev/virtio-ports/org.qemu.guest_agent.0.

Чтобы этот канал существовал, в Domain XML виртуальной машины должен быть описан соответствующий контроллер и порт. Если машина создавалась с помощью virt-install (как мы разбирали ранее), этот канал обычно добавляется автоматически. Проверить его наличие можно, изучив конфигурацию:

virsh dumpxml fedora-srv-01 | grep -A 4 "org.qemu.guest_agent.0"

Ожидаемый вывод должен содержать блок <channel>:

<channel type='unix'>
  <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-1-fedora-srv-01/org.qemu.guest_agent.0'/>
  <target type='virtio' name='org.qemu.guest_agent.0'/>
  <address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>

Если этого блока нет, его необходимо добавить через virsh edit, после чего полностью выключить и включить виртуальную машину (команды перезагрузки изнутри гостевой ОС будет недостаточно, так как требуется перестроение аппаратной топологии QEMU).

Установка и активация агента

Наличие канала связи — это лишь аппаратная (виртуальная) база. Внутри самой Fedora 44 необходимо установить службу, которая будет слушать этот порт, принимать команды в формате JSON, выполнять их и возвращать результат.

Подключившись к виртуальной машине (через консоль или SPICE), устанавливаем пакет:

sudo dnf install qemu-guest-agent

Служба должна быть добавлена в автозагрузку и запущена:

sudo systemctl enable --now qemu-guest-agent

Проверить работоспособность агента со стороны хоста можно простейшим запросом — например, запросив текущее время гостевой системы:

virsh domtime fedora-srv-01

Если команда возвращает время, значит, двусторонний канал связи через virtio-serial функционирует корректно.

Управление состоянием: ACPI против Guest Agent

Исторически для мягкого выключения виртуальных машин использовался протокол ACPI (Advanced Configuration and Power Interface). Команда virsh shutdown отправляла гостевой ОС сигнал ACPI Power Button.

Проблема этого подхода кроется в том, как операционные системы обрабатывают этот сигнал. В серверной версии Linux без графического интерфейса система, скорее всего, инициирует корректный процесс остановки служб. Однако, если установлена графическая оболочка (или определенные правила PolicyKit), система может проигнорировать сигнал или вывести диалоговое окно с вопросом: «Вы действительно хотите выключить компьютер?», ожидая действий пользователя. Для автоматизированных скриптов администрирования это означает зависание задачи.

Когда установлен qemu-guest-agent, libvirt меняет свое поведение. При выполнении virsh shutdown гипервизор сначала пытается отправить команду выключения напрямую через агента. Агент, работая с правами root, напрямую вызывает системный вызов завершения работы, обходя любые пользовательские интерфейсы и диалоги. Только если агент не отвечает, libvirt откатывается к отправке ACPI-сигнала.

Вы можете принудительно указать метод выключения с помощью флага --mode:

virsh shutdown fedora-srv-01 --mode agent

Согласованность данных: механизм fsfreeze

Одна из самых критичных задач системного администратора — обеспечение консистентности (согласованности) данных при резервном копировании. Если сделать снимок диска (snapshot) работающей машины, результат будет эквивалентен внезапному отключению питания. Данные, находившиеся в кэше оперативной памяти и не успевшие сброситься на диск, будут потеряны. Файловая система в снимке окажется в «грязном» состоянии.

Агент решает эту проблему через механизм заморозки файловой системы. Команда virsh domfsfreeze приказывает агенту инициировать системный вызов FIFREEZE (или FS_IOC_FIFREEZE) для всех смонтированных файловых систем.

Процесс происходит следующим образом:

1. Агент отправляет ядру гостевой ОС команду на сброс всех буферов и кэшей на диск (sync).
2. Ядро блокирует любые новые операции записи на файловую систему. Процессы, пытающиеся записать данные, переводятся в состояние ожидания (sleep).
3. Агент рапортует хосту, что файловая система заморожена.

В этот момент хост может безопасно выполнить снимок диска. После создания снимка файловая система размораживается командой virsh domfsthaw.

# Заморозка
virsh domfsfreeze fedora-srv-01
# (Здесь выполняется создание снимка)
# Разморозка
virsh domfsthaw fedora-srv-01

Пользовательские хуки (fsfreeze-hook)

Сброса кэшей файловой системы достаточно для целостности самой ФС, но может быть недостаточно для сложных приложений, таких как базы данных (PostgreSQL, MySQL). База данных может держать собственные структуры в памяти, и простая заморозка ФС на уровне ядра не гарантирует консистентности транзакций.

Для этого qemu-guest-agent поддерживает механизм хуков. В гостевой системе в директории /etc/qemu-ga/fsfreeze-hook.d/ можно разместить исполняемые скрипты. При вызове заморозки агент сначала выполнит эти скрипты с аргументом freeze, а при разморозке — с аргументом thaw.

Пример логики скрипта для базы данных:

• При получении freeze скрипт подключается к БД, выполняет команду FLUSH TABLES WITH READ LOCK (для MySQL) и приостанавливает работу.
• Файловая система замораживается на уровне ядра.
• Происходит создание снимка на хосте.
• Файловая система размораживается.
• Скрипт получает thaw и выполняет UNLOCK TABLES.

Использование domfsfreeze является абсолютно обязательным фундаментом перед переходом к созданию live-снимков.

Синхронизация времени и борьба с дрейфом

В виртуализированных средах время течет иначе, чем на физическом железе. Виртуальная машина может быть поставлена на паузу (virsh suspend), мигрирована на другой хост или просто недополучить процессорные такты из-за высокой нагрузки (CPU Steal Time).

Если виртуальная машина была приостановлена на 10 минут, при её пробуждении (virsh resume) внутренние часы гостевой ОС будут отставать ровно на 10 минут. Математически это выражается как накопленная ошибка $\Delta t = t_{host} - t_{guest}$, где $t_{guest}$ замирает в момент паузы. Дрейф времени критичен для криптографических протоколов (TLS-сертификаты, Kerberos), которые откажутся работать при рассинхронизации даже в несколько минут.

Стандартные демоны NTP (Network Time Protocol) или Chrony внутри гостя могут не справиться с резким скачком, так как они рассчитаны на плавную корректировку микросекундных отклонений.

qemu-guest-agent позволяет гипервизору принудительно синхронизировать время гостя с аппаратными часами хоста в обход сети:

virsh domtime fedora-srv-01 --sync

Многие современные инструменты управления виртуализацией автоматически отправляют эту команду через агента сразу после возобновления работы машины или завершения её миграции.

Извлечение метаданных и сетевой информации

В повседневной работе администратору часто нужно узнать IP-адрес виртуальной машины, чтобы подключиться к ней по SSH. Если IP выдается по DHCP, он может меняться.

Без агента команда virsh domifaddr пытается извлечь адрес, анализируя аренды (leases) встроенного в libvirt DHCP-сервера (dnsmasq) или перехватывая ARP-пакеты. Это ненадежно: если машина использует статический IP-адрес, настроенный внутри ОС, или получает адрес от внешнего корпоративного DHCP-сервера, libvirt ничего не покажет.

С установленным агентом мы можем запросить информацию напрямую у сетевого стека гостевой ОС:

virsh domifaddr fedora-srv-01 --source agent

В этом случае агент выполняет системные вызовы внутри гостя, собирает все назначенные адреса (включая IPv6 и алиасы) и передает их хосту.

Кроме сети, агент позволяет получить список смонтированных файловых систем, информацию о версии ядра и дистрибутиве:

virsh guestinfo fedora-srv-01

Вывод этой команды покажет детальную сводку: от имени хоста (hostname) внутри гостя до списка активных пользователей.

Прямое выполнение команд через QEMU Monitor

Одной из самых мощных, но редко используемых функций qemu-guest-agent является возможность выполнять произвольные команды внутри гостевой системы прямо с хоста, не используя SSH, не зная паролей и не имея сетевой связности. Это спасает в ситуациях, когда администратор случайно заблокировал доступ через брандмауэр внутри гостя (firewalld или iptables).

Взаимодействие происходит через QMP (QEMU Machine Protocol) путем передачи JSON-сообщений. Процесс состоит из двух этапов, так как выполнение команды асинхронно.

Сначала мы отправляем команду на запуск процесса с помощью guest-exec. В аргументах необходимо передать абсолютный путь к исполняемому файлу и массив аргументов.

virsh qemu-agent-command fedora-srv-01 '{"execute": "guest-exec", "arguments": {"path": "/usr/bin/systemctl", "arg": ["stop", "firewalld"], "capture-output": true}}'

Обратите внимание на синтаксис: вся JSON-структура оборачивается в одинарные кавычки. Флаг "capture-output": true приказывает агенту сохранить стандартный вывод (stdout) и ошибки (stderr) запущенного процесса.

В ответ QEMU вернет JSON с идентификатором процесса (PID):

{"return": {"pid": 1452}}

Вторым этапом мы запрашиваем статус выполнения по этому PID с помощью guest-exec-status:

virsh qemu-agent-command fedora-srv-01 '{"execute": "guest-exec-status", "arguments": {"pid": 1452}}'

Ответ будет содержать код возврата (exitcode) и, если был запрошен захват вывода, сам вывод в формате base64:

{"return": {"exitcode": 0, "out-data": "", "exited": true}}

Этот механизм позволяет строить надежные системы автоматизации инициализации виртуальных машин (provisioning), когда скрипты настройки проталкиваются в систему сразу после её клонирования, еще до того, как поднимется сеть.

Оптимизация энтропии: устройство VirtIO-RNG

Хотя эта тема выходит за рамки исключительно программного агента, она тесно связана с оптимизацией внутренних процессов гостевой ОС. Операционным системам для криптографических операций (генерация SSH-ключей, установка TLS-соединений, шифрование дисков) требуется качественный источник случайных чисел (энтропия).

На физическом сервере энтропия собирается из непредсказуемых аппаратных событий: прерываний клавиатуры, движений мыши, колебаний температуры дисков, задержек сетевых пакетов. Виртуальная машина лишена большинства этих источников. В результате пул энтропии (доступный через /dev/random) может исчерпаться, что приведет к блокировке криптографических операций до накопления новых случайных данных. Загрузка ОС или генерация ключей может необъяснимо зависнуть на несколько минут.

Чтобы решить эту проблему, KVM позволяет пробросить аппаратный генератор случайных чисел хоста внутрь гостевой системы с помощью паравиртуального устройства VirtIO-RNG (Random Number Generator).

Для его включения необходимо добавить в Domain XML следующее устройство:

<rng model='virtio'>
  <backend model='random'>/dev/urandom</backend>
  <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
</rng>

В качестве источника (backend) на хосте мы используем неблокирующий /dev/urandom. Драйвер virtio-rng в ядре гостевой Fedora 44 автоматически подхватит это устройство и начнет подмешивать получаемые от гипервизора случайные байты в собственный пул энтропии. Это радикально ускоряет все криптографические операции внутри виртуальной машины и исключает задержки при старте сервисов, требующих генерации ключей.

Интеграция гостевой системы с гипервизором не ограничивается простым выделением ресурсов. Установка и правильная эксплуатация агента, наряду с использованием паравиртуальных устройств, стирает границу между хостом и виртуальной машиной. Гипервизор получает возможность безопасно управлять питанием, гарантировать целостность данных перед резервным копированием, синхронизировать время и выполнять команды восстановления даже в условиях полной сетевой изоляции. Эти механизмы закладывают основу для построения отказоустойчивой инфраструктуры, где виртуальные машины реагируют на команды администратора предсказуемо и безопасно.

Управление жизненным циклом виртуальных машин и настройка политик автозапуска

Внезапная перезагрузка хост-сервера из-за сбоя питания или плановое обновление ядра ОС не должны приводить к повреждению баз данных внутри виртуальных машин. Системный администратор контролирует не только выделение ресурсов, но и то, как именно гипервизор обрабатывает сигналы остановки, в какой последовательности стартуют сервисы и что происходит с оперативной памятью гостевых систем при экстренном обслуживании оборудования. Управление жизненным циклом (Lifecycle Management) в KVM — это строгий набор состояний и переходов, определяющих поведение процесса QEMU в операционной системе Fedora 44.

Конечный автомат состояний домена

В терминологии libvirt виртуальная машина называется доменом (domain). Каждый домен в любой момент времени находится в одном из строго определенных состояний. Понимание этих состояний необходимо для предсказуемого управления инфраструктурой.

Базовая команда мониторинга virsh list по умолчанию отображает только активные домены. Для получения полной картины используется флаг --all.

virsh list --all

Возможные состояния домена в libvirt:

• running — процесс QEMU запущен, гостевая ОС выполняет инструкции на выделенных vCPU.
• paused — выполнение инструкций vCPU приостановлено гипервизором. Процесс QEMU существует, оперативная память домена удерживается в RAM хоста, но процессорное время не потребляется.
• shut off — домен выключен. Процесс QEMU завершен, ресурсы (RAM, vCPU) освобождены. Конфигурация (XML) сохранена в системе.
• in shutdown — переходное состояние. Гипервизор отправил сигнал на выключение, и гостевая ОС находится в процессе остановки своих служб.
• saved — состояние домена (содержимое RAM и регистров процессора) сброшено на физический диск хоста. Процесс QEMU остановлен, но при следующем запуске система продолжит работу с того же места.
• crashed — процесс QEMU завершился аварийно (например, из-за ошибки сегментации или принудительного убийства процесса гипервизором на уровне ядра).

Для точечной проверки состояния конкретной машины используется команда virsh domstate fedora-srv-01, которая удобна для использования в bash-скриптах автоматизации.

Механизмы выключения: от ACPI до QMP

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

Штатное выключение (Graceful Shutdown)

Команда virsh shutdown <domain> сообщает гостевой операционной системе о необходимости завершить работу. По умолчанию libvirt пытается использовать событие ACPI (Advanced Configuration and Power Interface) — виртуальный эквивалент кратковременного нажатия на физическую кнопку питания сервера.

Если в гостевой ОС не настроен обработчик ACPI-событий (например, отключен демон systemd-logind или acpid), команда будет проигнорирована, и машина останется в состоянии running.

Для гарантированного и безопасного выключения используется интеграция с qemu-guest-agent, архитектуру которого мы разбирали ранее. Агент позволяет передать команду на выключение напрямую через канал virtio-serial в обход ACPI.

virsh shutdown fedora-srv-01 --mode agent

В этом случае демон qemu-guest-agent внутри гостя инициирует стандартный процесс выключения (эквивалент команды poweroff внутри самой VM), корректно останавливая базы данных и сбрасывая кэши файловой системы на диск.

Аварийная остановка (Destroy)

Если гостевая ОС зависла (kernel panic) и не реагирует ни на ACPI, ни на команды агента, применяется жесткая остановка.

virsh destroy fedora-srv-01

Термин destroy в libvirt означает не удаление самой виртуальной машины, а немедленное уничтожение процесса QEMU на хосте. Гипервизор отправляет процессу сигнал SIGKILL. Это эквивалентно выдергиванию шнура питания из розетки физического сервера. Файловые системы гостя не размонтируются, данные в кэшах теряются, что при следующем запуске приведет к необходимости восстановления журналов ФС (fsck). Использовать эту команду следует исключительно как крайнюю меру.

Управление контекстом выполнения: Пауза и Сохранение

При обслуживании хост-сервера (например, при необходимости временно освободить ресурсы для тяжелой задачи) администратору доступны два механизма временной остановки VM.

Приостановка (Suspend)

Команда virsh suspend <domain> мгновенно замораживает выполнение домена. Гипервизор KVM перестает планировать потоки vCPU этой машины на физических ядрах.

Важный нюанс: при выполнении suspend оперативная память виртуальной машины (например, выделенные 4 Гб) продолжает оставаться зарезервированной в RAM хост-сервера Fedora 44.

Этот метод идеален для кратковременной фиксации состояния (например, перед созданием LVM-снимка хранилища на уровне хоста). Для возврата машины к работе используется команда virsh resume <domain>. Гостевая ОС не замечает факта остановки, за исключением скачкообразного изменения системного времени, которое затем корректируется через NTP или qemu-guest-agent.

Управляемое сохранение (Managed Save)

Если необходимо освободить не только процессорное время, но и оперативную память хоста, применяется механизм managedsave.

virsh managedsave fedora-srv-01

При вызове этой команды гипервизор ставит QEMU на паузу, а затем последовательно записывает всё содержимое выделенной оперативной памяти гостя и состояние регистров vCPU в специальный файл на диске хоста (по умолчанию в директорию /var/lib/libvirt/qemu/save/). После завершения записи процесс QEMU уничтожается, память освобождается, а домен переходит в состояние saved.

Время выполнения этой операции напрямую зависит от объема RAM виртуальной машины и скорости дисковой подсистемы. Сохранение машины с 32 Гб RAM на медленный HDD может занять несколько минут.

Восстановление происходит автоматически при стандартной команде запуска:

virsh start fedora-srv-01

Libvirt обнаруживает наличие файла сохранения, загружает его содержимое обратно в RAM и возобновляет работу процессоров. Файл сохранения после успешного старта удаляется. Если сохраненное состояние больше не актуально (например, администратор решил загрузить машину с нуля), файл сохранения можно принудительно сбросить командой virsh managedsave-remove <domain>.

Полное удаление виртуальной машины (Undefine)

Жизненный цикл машины заканчивается её удалением. В libvirt этот процесс разделен на остановку и удаление конфигурации. Команда virsh undefine <domain> удаляет XML-конфигурацию машины из директории /etc/libvirt/qemu/, делая её невидимой для гипервизора.

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

Во-первых, если машина использовала UEFI (OVMF), её конфигурация включает отдельный файл NVRAM (энергонезависимой памяти), где хранятся переменные загрузчика EFI. Попытка удалить такую машину стандартной командой завершится ошибкой, так как libvirt защищает файл NVRAM от случайного удаления.

Во-вторых, undefine по умолчанию не трогает дисковые образы (Storage Volumes). Если цель — полностью очистить место на сервере, необходимо явно указать гипервизору удалить связанные хранилища.

Комплексная команда для полного и бесследного удаления виртуальной машины вместе с её дисками и переменными UEFI выглядит так:

virsh undefine fedora-srv-01 --nvram --remove-all-storage

Флаг --remove-all-storage удалит все диски, описанные в XML-конфигурации домена, из пула /mnt/kvm-data. Если некоторые диски нужно сохранить (например, диск с пользовательскими данными, подключенный как дополнительный том), их следует отсоединить (detach-disk) до выполнения undefine.

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

После настройки виртуальной инфраструктуры необходимо обеспечить её отказоустойчивость при перезагрузке хост-сервера. Базовый механизм libvirt для решения этой задачи — флаг автозапуска.

virsh autostart fedora-srv-01

Под капотом эта команда не вносит изменений в XML-файл самой машины. Вместо этого она создает символическую ссылку на конфигурационный файл домена в специальной директории /etc/libvirt/qemu/autostart/. При старте демона libvirtd (или модульного qemu-networkd/qemu-systemd в новых релизах) гипервизор сканирует эту директорию и инициирует запуск всех найденных машин.

Отключение автозапуска выполняется симметрично:

virsh autostart --disable fedora-srv-01

Главное ограничение встроенного механизма autostart — полное отсутствие управления зависимостями. Libvirt запускает машины асинхронно. Если app-server требует для своей работы полностью загруженного db-server, базовый автозапуск не сможет обеспечить задержку старта приложения до момента готовности базы данных. Гипервизор просто отправит команды на старт процессов QEMU одновременно.

Глобальная оркестрация через libvirt-guests

Для решения проблем с зависимостями и обеспечения корректного поведения всех виртуальных машин при выключении самого хоста Fedora 44 применяется системная служба libvirt-guests.service.

Эта служба интегрируется в процесс выключения (shutdown/reboot) хост-ОС через systemd. По умолчанию, если администратор отправляет сервер в перезагрузку, systemd просто посылает сигнал SIGTERM, а затем SIGKILL всем процессам, включая QEMU. Это приводит к сценарию virsh destroy для всех запущенных машин, что недопустимо в рабочей среде.

Служба libvirt-guests перехватывает процесс выключения хоста и корректно обрабатывает состояния виртуальных машин согласно правилам, заданным в конфигурационном файле /etc/libvirt/libvirt-guests.conf.

Конфигурация поведения при выключении хоста

Ключевой параметр файла конфигурации — ON_SHUTDOWN. Он определяет, что должна сделать служба с запущенными машинами, когда хост Fedora 44 начинает перезагрузку или выключение.

Доступны два значения:

1. ON_SHUTDOWN=shutdown — служба последовательно отправит команду штатного выключения (ACPI или agent) каждой запущенной машине и будет ждать их полной остановки.
2. ON_SHUTDOWN=suspend — служба выполнит managedsave для каждой машины, сбросив их оперативную память на диск.

Выбор между shutdown и suspend зависит от архитектуры сервисов. suspend позволяет вернуть инфраструктуру в работу ровно в том состоянии, в котором она была, без потери установленных сетевых соединений внутри гостя. Однако, если хост обновляет ядро или микрокод процессора, восстановление из managedsave может привести к сбоям, так как аппаратный контекст изменится. В таких случаях предпочтительнее чистый shutdown.

Управление временем ожидания и параллелизмом

При использовании ON_SHUTDOWN=shutdown критически важно настроить таймауты. Если гостевая ОС зависла и не выключается, хост-сервер может бесконечно висеть в процессе перезагрузки, ожидая завершения работы виртуальной машины.

Параметр SHUTDOWN_TIMEOUT задает максимальное время (в секундах), которое служба будет ждать выключения одной машины. Если по истечении этого времени процесс QEMU всё еще активен, служба принудительно завершит его (destroy), чтобы позволить хосту продолжить перезагрузку.

Параметр PARALLEL_SHUTDOWN (по умолчанию 0) определяет, будут ли машины выключаться по очереди или одновременно. Если машин много, последовательное выключение может занять недопустимо много времени. Общее время ожидания хоста при последовательном выключении вычисляется как:

$T_{total} = N \times T_{timeout}$

где $N$ — количество запущенных виртуальных машин, а $T_{timeout}$ — значение SHUTDOWN_TIMEOUT. Если на хосте запущено 10 машин, а таймаут равен 300 секундам, перезагрузка хоста может занять до 50 минут.

Установка PARALLEL_SHUTDOWN=10 заставит службу отправить сигнал выключения сразу 10 машинам одновременно. В этом случае общее время ожидания будет равно одному таймауту (300 секунд), независимо от того, зависла одна машина или все десять.

Восстановление состояния при загрузке хоста

Служба libvirt-guests также контролирует поведение машин при старте хост-сервера через параметр ON_BOOT.

Значение ON_BOOT=start указывает службе запустить только те виртуальные машины, которые находились в состоянии running на момент начала выключения хоста. Это гораздо более интеллектуальный подход, чем слепой virsh autostart. Если администратор вручную остановил тестовую виртуальную машину перед перезагрузкой сервера, libvirt-guests запомнит этот факт (сохранив список состояний в /var/lib/libvirt/libvirt-guests) и не станет запускать её после загрузки хоста.

Значение ON_BOOT=ignore отключает эту логику, передавая ответственность за запуск машин стандартному механизму autostart или внешним системам оркестрации.

Интеграция libvirt-guests в связке с правильно настроенным qemu-guest-agent формирует замкнутый и безопасный контур управления. Администратор получает уверенность в том, что при любом плановом обслуживании физического оборудования или сбое по питанию (при наличии ИБП, корректно инициирующего shutdown хоста), виртуальные диски останутся консистентными, а сервисы вернутся к работе в предсказуемом состоянии без ручного вмешательства.

Работа с внешними устройствами и динамический проброс USB-устройств «на лету»

Аппаратный USB-ключ лицензирования HASP для бухгалтерского ПО, GSM-модем для корпоративной АТС или специализированный криптографический токен для подписания документов — физические устройства, которые периодически требуется интегрировать в виртуальную среду. Остановка продуктивного сервера для добавления нового оборудования в конфигурацию неприемлема. Архитектура KVM и libvirt позволяет управлять жизненным циклом периферийных устройств без прерывания работы гостевой ОС, используя механизмы горячего подключения (hotplug).

Проброс USB-устройств (USB passthrough) в KVM реализуется двумя принципиально разными путями. Первый — серверный проброс (Host-side passthrough), при котором физическое устройство вставляется непосредственно в порт хост-сервера Fedora 44 и передается виртуальной машине средствами libvirt. Второй — клиентский проброс (Client-side passthrough), когда администратор подключает устройство в свой рабочий ноутбук и пробрасывает его по сети через протокол SPICE прямо в гостевую систему.

Архитектура USB-контроллеров в QEMU/KVM

Чтобы гостевая операционная система могла обнаружить подключенное устройство, виртуальная материнская плата должна обладать соответствующим контроллером шины USB. QEMU эмулирует аппаратные контроллеры нескольких поколений: UHCI (USB 1.1), EHCI (USB 2.0) и XHCI (USB 3.0).

При создании виртуальной машины с чипсетом Q35 (современный стандарт, который мы использовали ранее) контроллер добавляется автоматически, однако для обеспечения максимальной пропускной способности и совместимости с современными устройствами конфигурацию контроллера следует явно определить в формате XHCI.

В Domain XML виртуальной машины блок контроллера выглядит следующим образом:

<controller type='usb' index='0' model='qemu-xhci' ports='15'>
  <alias name='usb'/>
  <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</controller>

Параметр model='qemu-xhci' указывает гипервизору использовать паравиртуализированную реализацию контроллера USB 3.0. Атрибут ports='15' определяет максимальное количество устройств, которые можно одновременно подключить к этой виртуальной шине. Если в конфигурации присутствует устаревший контроллер piix3-uhci, его рекомендуется заменить на qemu-xhci с помощью команды virsh edit, предварительно остановив виртуальную машину, так как изменение типа корневого контроллера «на лету» невозможно.

Серверный проброс устройств (Host-side USB Passthrough)

Этот метод применяется для стационарного оборудования, которое физически находится в серверной стойке и подключено к портам хоста на базе Fedora 44. Процесс горячего подключения состоит из идентификации устройства на хосте, формирования XML-манифеста устройства и его внедрения в работающий процесс QEMU.

Идентификация оборудования на хосте

Для получения списка физически подключенных устройств используется утилита lsusb. Вывод команды на хосте Fedora 44 предоставляет необходимую адресацию:

Bus 002 Device 004: ID 04b9:0300 SafeNet Inc. HASP HL
Bus 002 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 8087:800a Intel Corp. Hub

Каждое устройство характеризуется двумя парами идентификаторов. Первая пара — логическая топология: номер шины (Bus 002) и номер устройства на шине (Device 004). Вторая пара — аппаратная сигнатура: идентификатор производителя (Vendor ID 04b9) и идентификатор продукта (Product ID 0300).

Libvirt поддерживает оба метода адресации для проброса, но они имеют разные сценарии применения и уровни надежности.

Адресация по Bus/Device жестко привязывает проброс к конкретному физическому порту и порядку инициализации. Если сервер перезагрузить или переткнуть USB-ключ в соседний порт, номер Device изменится (например, станет 006), и libvirt не сможет найти устройство при следующем запуске виртуальной машины.

Адресация по Vendor/Product (Рекомендуемая) опирается на аппаратные идентификаторы. Независимо от того, в какой порт вставлен ключ 04b9:0300, libvirt найдет его и передаст в гостевую систему. Исключение составляет ситуация, когда в сервер вставлено два абсолютно одинаковых устройства (с идентичными Vendor/Product ID) — в этом случае libvirt пробросит первое найденное, что может привести к непредсказуемому поведению, и тогда придется использовать адресацию по Bus/Device.

Формирование XML-манифеста устройства

Для горячего подключения необходимо создать отдельный XML-файл, описывающий пробрасываемое устройство. Создадим файл hasp-token.xml для ключа SafeNet:

<hostdev mode='subsystem' type='usb' managed='yes'>
  <source>
    <vendor id='0x04b9'/>
    <product id='0x0300'/>
  </source>
</hostdev>

Ключевой атрибут здесь — managed='yes'. Он инструктирует демон libvirtd автоматически отвязать устройство от драйверов хостовой операционной системы (если они были загружены ядром Fedora 44) перед передачей устройства гипервизору, а также вернуть устройство под управление хоста после выключения виртуальной машины или отсоединения устройства. Без этого флага попытка проброса устройства, занятого хостом, завершится ошибкой доступа.

Выполнение горячего подключения (Hotplug)

Добавление устройства в работающую гостевую систему выполняется командой virsh attach-device.

virsh attach-device fedora-srv-01 hasp-token.xml --live --config

Флаги определяют область применения изменений:

• --live применяет конфигурацию к текущему состоянию оперативной памяти процесса QEMU. Устройство появляется в гостевой системе мгновенно. Если виртуальная машина будет перезагружена, изменение исчезнет.
• --config записывает конфигурацию в постоянный Domain XML виртуальной машины на диске. Это гарантирует, что при следующем холодном старте устройство снова будет проброшено.

Использование обоих флагов одновременно обеспечивает и мгновенное подключение, и персистентность конфигурации.

После выполнения команды в логах ядра гостевой системы (через dmesg или journalctl -k) появится сообщение об обнаружении нового USB-устройства на шине XHCI, после чего гостевая ОС инициирует загрузку соответствующих драйверов.

Горячее отключение (Hot-unplug)

Извлечение устройства из виртуальной машины должно производиться программно до физического извлечения из порта сервера. Это предотвращает повреждение данных (особенно для USB-накопителей) и зависание драйверов в гостевой ОС.

virsh detach-device fedora-srv-01 hasp-token.xml --live --config

Команда отправляет ACPI-сигнал гостевой системе на безопасное извлечение оборудования. Только после успешного завершения этой команды устройство можно физически вытаскивать из сервера.

Нюансы физического переподключения

Если физическое устройство, проброшенное с флагом --config, вытащить из USB-порта хоста во время работы виртуальной машины, процесс QEMU корректно обработает это событие: устройство исчезнет из гостевой системы.

Сложность возникает при возвращении устройства в порт. Демон libvirtd не сканирует шину USB непрерывно. Если вставить ключ обратно, он появится на хосте Fedora 44, но не пробросится автоматически в работающую виртуальную машину, несмотря на наличие записи в Domain XML.

Для автоматизации возврата устройства применяются правила udev на хосте. При обнаружении специфического Vendor/Product ID подсистема udev может инициировать скрипт, вызывающий virsh attach-device. Однако в базовом администрировании надежнее выполнить повторное присоединение вручную или перезагрузить виртуальную машину (при старте libvirt считывает XML и захватывает все доступные устройства).

Клиентский проброс устройств (Client-side USB Passthrough через SPICE)

В сценариях удаленного администрирования физический доступ к серверу отсутствует. Если администратору необходимо передать файлы с локальной флешки в изолированную виртуальную машину или подключить токен ЭЦП со своего рабочего места, используется технология перенаправления USB через протокол SPICE (usbredir).

Механика работы usbredir

Протокол SPICE инкапсулирует USB-трафик на уровне URB (USB Request Blocks) и передает его по сети. На стороне клиента (ноутбука администратора) приложение remote-viewer захватывает локальное устройство, блокируя к нему доступ со стороны клиентской ОС. На стороне сервера QEMU принимает этот сетевой поток и транслирует его в виртуальный USB-контроллер так, будто устройство физически подключено к серверу.

Подготовка конфигурации виртуальной машины

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

Редактирование конфигурации выполняется через virsh edit fedora-srv-01. В блок <devices> добавляются следующие строки:

<redirdev bus='usb' type='spicevmc'>
  <alias name='redir0'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
  <alias name='redir1'/>
</redirdev>

Тип spicevmc указывает, что данные будут маршрутизироваться через основной коммуникационный канал SPICE, который мы ранее защищали SSH-туннелем. Изменения вступят в силу только после полного выключения и повторного запуска виртуальной машины (команды virsh destroy или virsh shutdown, затем virsh start).

Процесс подключения со стороны клиента

Подключение устройства инициируется из графического интерфейса клиента. После установки соединения с виртуальной машиной через remote-viewer (например, remote-viewer spice://127.0.0.1:5900 при поднятом SSH-туннеле), администратор открывает меню окна и выбирает пункт «File» → «USB device selection».

В появившемся диалоговом окне отображается список всех USB-устройств, подключенных к локальному компьютеру администратора. Установка галочки напротив нужного устройства инициирует процесс перенаправления.

С этого момента устройство исчезает из локальной системы и появляется внутри гостевой ОС. Отключение происходит снятием галочки в том же меню.

Ограничения и расчет пропускной способности

При использовании usbredir критическим фактором становится сетевая инфраструктура. USB-трафик крайне чувствителен к задержкам (latency) и требует высокой пропускной способности.

Передача данных с USB 3.0 накопителя через SPICE ограничена не скоростью диска, а шириной сетевого канала и накладными расходами протокола. Математическая модель времени передачи файла выглядит так:

$T_{transfer} = \frac{V}{B_{net} \times (1 - E)}$

Где $V$ — объем передаваемых данных, $B_{net}$ — физическая пропускная способность сети между клиентом и сервером, а $E$ — коэффициент накладных расходов на инкапсуляцию SPICE и шифрование SSH-туннеля (обычно составляет от $0.1$ до $0.2$).

При попытке пробросить внешний жесткий диск через интернет-канал с высокой задержкой, операции ввода-вывода внутри гостевой ОС могут завершаться по таймауту (I/O timeout), что приведет к перемонтированию файловой системы в режим read-only. Клиентский проброс идеально подходит для низкоскоростных устройств: смарт-карт, аппаратных ключей, сканеров штрих-кодов и USB-COM адаптеров. Для массовой передачи файлов следует использовать сетевые протоколы (SMB, NFS, SFTP), а не проброс физического накопителя.

Интеграция с подсистемами безопасности (sVirt и cgroups)

При серверном пробросе устройств (Host-side) на Fedora 44 администратор может столкнуться с ошибкой вида Permission denied при попытке выполнить virsh attach-device, даже если команда запущена от имени root. Это следствие работы защитных механизмов sVirt (SELinux) и контрольных групп (cgroups).

Когда libvirt получает команду на проброс устройства, он выполняет несколько скрытых операций:

1. Находит файл символьного устройства в /dev/bus/usb/.
2. Изменяет владельца этого файла на пользователя qemu.
3. Модифицирует правила cgroups для процесса конкретной виртуальной машины, разрешая доступ к мажорному и минорному номеру этого устройства.
4. Присваивает файлу устройства динамический контекст SELinux (например, system_u:object_r:svirt_image_t:s0:c123,c456), который совпадает с контекстом запущенного процесса QEMU.

Сбой на любом из этих этапов блокирует проброс. Частая причина — вмешательство сторонних правил udev на хосте. Если администратор написал собственное правило udev, которое принудительно устанавливает права 0600 и владельца root:root на USB-ключ, это правило может сработать позже, чем libvirt попытается передать устройство процессу QEMU. В результате файл в /dev/bus/usb/ снова станет принадлежать root, и процесс QEMU, работающий от непривилегированного пользователя, потеряет доступ к аппаратному обеспечению, что приведет к зависанию драйвера внутри гостевой системы.

Диагностика таких проблем начинается с проверки аудита SELinux на хосте: ausearch -m AVC -ts recent. Если обнаружены блокировки, связанные с USB-устройствами и процессом qemu-system-x86_64, необходимо пересмотреть приоритеты правил udev и убедиться, что демон libvirtd имеет монопольное право на управление правами доступа к пробрасываемому узлу.

Проблема сброса устройств (USB Reset Quirks)

Еще один глубокий технический нюанс связан с процессом инициализации. При передаче устройства в виртуальную машину гипервизор отправляет команду сброса (USB Reset) на контроллер, чтобы привести устройство в исходное состояние.

Некоторые дешевые микроконтроллеры, нестандартные USB-to-Serial адаптеры и старые принтеры нарушают спецификацию USB и зависают при получении сигнала сброса от хоста. В таких случаях устройство успешно пробрасывается (команда virsh attach-device завершается без ошибок), оно видно в выводе lsusb внутри гостевой ОС, но не реагирует на запросы драйвера.

Решение этой проблемы требует вмешательства в параметры модуля ядра usbcore на хосте Fedora 44 или использования специфических флагов (quirks), отключающих аппаратный сброс для конкретного Vendor/Product ID. Однако в рамках стандартного управления KVM важно понимать сам симптом: если устройство проброшено, но не функционирует внутри гостя, проблема чаще всего кроется не в libvirt, а в реакции прошивки (firmware) самого физического устройства на виртуализацию шины.

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

Механизмы снимков системы: создание, управление и восстановление состояний

Обновление критически важного сервиса на сервере базы данных прошло неудачно: новые пакеты вызвали конфликт зависимостей, служба systemd ушла в циклический рестарт, а простой измеряется минутами. Восстановление из полноценной резервной копии займет часы из-за объема данных. В таких сценариях на первый план выходит механизм снимков (snapshots) виртуальных машин — инструмент, позволяющий зафиксировать текущее состояние диска и оперативной памяти, чтобы при необходимости откатиться к нему за несколько секунд. Снимки не заменяют резервное копирование, так как физически зависят от исходного дискового образа, но они являются фундаментальным инструментом системного администратора для безопасного проведения изменений.

В стеке KVM и libvirt управление снимками реализовано на стыке возможностей гипервизора QEMU и форматов дисковых образов. Для эффективной работы с ними необходимо понимать архитектурные различия между типами снимков, механизмы обеспечения консистентности данных и нюансы работы с цепочками дисковых образов.

Архитектура снимков: внутренние и внешние

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

Внутренние снимки (Internal Snapshots)

При использовании внутренних снимков и оригинальные данные, и все дельты (изменения) хранятся внутри одного физического файла формата QCOW2. Когда администратор инициирует создание снимка, QEMU сохраняет текущее состояние таблиц размещения блоков QCOW2. Все последующие операции записи со стороны гостевой ОС направляются в новые, свободные блоки того же файла, а старые блоки помечаются как принадлежащие снимку и становятся доступны только для чтения.

Преимущества внутренних снимков заключаются в невероятной простоте управления: файл виртуального диска остается один, его легко переносить на другой хост, а команды libvirt для отката и удаления работают прозрачно и предсказуемо.

Однако этот подход имеет серьезные архитектурные ограничения. Процесс создания внутреннего снимка работающей машины требует кратковременной приостановки (паузы) процесса QEMU. Чем выше нагрузка на дисковую подсистему гостя, тем дольше длится эта пауза, что может привести к разрыву сетевых соединений по таймауту. Кроме того, активное использование внутренних снимков приводит к сильной фрагментации файла QCOW2 и деградации производительности ввода-вывода.

Внешние снимки (External Snapshots)

Внешние снимки используют механизм цепочек образов (backing files). При создании внешнего снимка текущий файл QCOW2 переводится в режим «только чтение» (backing file), а рядом с ним создается новый, пустой файл QCOW2 (overlay). Гипервизор на лету переключает все новые операции записи в этот новый файл. Чтение происходит каскадно: если нужный блок есть в новом файле, он читается оттуда; если нет — запрос проваливается на уровень ниже, в базовый образ.

Характеристика	Внутренние снимки	Внешние снимки
Расположение данных	Внутри одного файла QCOW2	В новых файлах (overlay)
Скорость создания	Зависит от нагрузки, требует микропаузы	Мгновенно, без заметной паузы
Производительность I/O	Снижается из-за фрагментации файла	Снижается из-за глубины цепочки файлов
Поддержка форматов	Только QCOW2	Raw, QCOW2, LVM, блочные устройства
Сложность управления	Низкая (полная поддержка в libvirt)	Высокая (требует ручных операций с блоками)

Внешние снимки считаются более современным и производительным решением для production-сред, особенно при интеграции с внешними системами резервного копирования, однако их слияние и удаление требует глубокого понимания работы блочного слоя QEMU.

Консистентность данных при создании снимков

Снимок, сделанный в произвольный момент времени, фиксирует состояние диска «как есть». Если в этот момент база данных выполняла транзакцию и держала часть данных в кэше оперативной памяти, то на диске окажутся поврежденные или неполные структуры. Такое состояние называется crash-consistent — оно эквивалентно внезапному отключению питания сервера. Современные журналируемые файловые системы (ext4, xfs) обычно переживают это без потерь, но сложные СУБД могут потребовать длительного восстановления.

Для получения application-consistent снимка, при котором все данные гарантированно сброшены на диск, libvirt использует интеграцию с qemu-guest-agent. При передаче специального флага гипервизор отправляет агенту команду на заморозку файловой системы. Агент выполняет системный вызов, сбрасывающий кэши, и приостанавливает операции записи. Только после этого QEMU делает срез диска, а затем агент размораживает файловую систему. Этот процесс занимает доли секунды, но гарантирует целостность данных на уровне приложений.

Практика: управление внутренними снимками

Для работы со снимками используется группа команд virsh snapshot-*. Создадим внутренний снимок виртуальной машины fedora-srv-01 перед опасным обновлением.

virsh snapshot-create-as \
  --domain fedora-srv-01 \
  --name "pre-update" \
  --description "Snapshot before major DNF upgrade" \
  --atomic

Флаг --atomic гарантирует, что если у машины несколько дисков, снимок будет сделан либо для всех успешно, либо операция будет отменена полностью. Это исключает рассинхронизацию состояний между системным диском и диском с данными.

По умолчанию для работающей машины libvirt попытается сохранить не только состояние диска, но и дамп оперативной памяти. Это позволяет при откате вернуть машину ровно в ту секунду выполнения, на которой был сделан снимок. Однако сохранение 4 Гб RAM в файл QCOW2 займет время. Если требуется зафиксировать только состояние файловой системы (например, для отката неудачного обновления пакетов, после которого машина всё равно будет перезагружена), следует использовать флаг --disk-only.

Просмотр дерева снимков осуществляется командой:

virsh snapshot-list fedora-srv-01 --tree

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

virsh snapshot-revert fedora-srv-01 pre-update

При этом текущее состояние машины будет уничтожено, и она вернется в состояние pre-update. Если обновление прошло успешно и снимок больше не нужен, его необходимо удалить, чтобы освободить место внутри QCOW2 и снизить фрагментацию:

virsh snapshot-delete fedora-srv-01 pre-update

Процесс удаления внутреннего снимка выполняется гипервизором в фоновом режиме: QEMU объединяет блоки данных, актуальные для текущего состояния, и помечает старые блоки как свободные.

Практика: внешние снимки и управление цепочками

Создание внешнего снимка требует явного указания флага --disk-only (сохранение RAM во внешние файлы поддерживается, но сильно усложняет архитектуру) и использования qemu-guest-agent для консистентности.

virsh snapshot-create-as fedora-srv-01 \
  --name "ext-snap-1" \
  --disk-only \
  --quiesce \
  --atomic

Флаг --quiesce сообщает libvirt о необходимости использовать qemu-guest-agent для заморозки файловой системы перед созданием снимка. Если агент не отвечает или не установлен, команда завершится ошибкой.

После выполнения этой команды в директории /mnt/kvm-data/images/ произойдут изменения. Оригинальный файл fedora-srv-01.qcow2 останется на месте, но перестанет изменяться. Рядом появится новый файл, например fedora-srv-01.ext-snap-1, который станет активным диском для виртуальной машины.

Убедиться в этом можно, изучив цепочку backing files с помощью утилиты qemu-img:

qemu-img info --backing-chain /mnt/kvm-data/images/fedora-srv-01.ext-snap-1.qcow2

Вывод покажет, что новый файл ссылается на старый. Если сделать еще один снимок, цепочка удлинится. Каждое звено в этой цепочке увеличивает задержку чтения (latency). На практике не рекомендуется допускать ситуации, когда глубина цепочки $N \geq 3$, так как накладные расходы на поиск нужного блока по всем файлам начинают заметно влиять на производительность I/O.

Слияние внешних снимков (Blockcommit и Blockpull)

Главная сложность внешних снимков в libvirt заключается в том, что команда virsh snapshot-delete удалит только метаданные снимка из конфигурации, но не объединит физические файлы на диске. Оставив разорванную цепочку, вы рискуете потерять данные.

Для управления цепочками файлов используются блочные операции гипервизора. Существует два направления слияния:

1. Blockpull — вытягивание данных из базового (старого) образа в текущий (активный) overlay-файл.
2. Blockcommit — проталкивание данных из текущего overlay-файла вниз, в базовый образ.

Чаще всего администратору нужно удалить временный снимок, сохранив все изменения, сделанные после него. Для этого используется активный blockcommit.

Предположим, у нас есть цепочка: base.qcow2 <- snap1.qcow2 (активный диск). Мы хотим влить изменения из snap1 обратно в base и сделать base снова активным диском, не останавливая виртуальную машину.

virsh blockcommit fedora-srv-01 vda \
  --active \
  --verbose \
  --pivot

В этой команде vda — это целевое блочное устройство в гостевой ОС. Флаг --active разрешает операцию над текущим диском, в который идет запись. Процесс происходит в два этапа. Сначала QEMU в фоновом режиме копирует все измененные блоки из snap1 в base. Поскольку гостевая ОС продолжает работать и писать данные, гипервизор отслеживает новые изменения и синхронизирует их. Когда файлы становятся идентичными, вступает в силу флаг --pivot. Он дает команду QEMU мгновенно переключить файловый дескриптор: гипервизор отвязывается от snap1.qcow2 и начинает писать напрямую в base.qcow2.

После успешного завершения команды файл snap1.qcow2 становится сиротой — он больше не используется гипервизором, и его можно безопасно удалить командой rm на уровне хоста. Обязательно удалите метаданные снимка из libvirt, чтобы конфигурация оставалась чистой:

virsh snapshot-delete fedora-srv-01 ext-snap-1 --metadata

Ограничения и граничные случаи: UEFI и NVRAM

Одной из самых частых проблем при переходе на современные конфигурации виртуальных машин является несовместимость внутренних снимков с прошивкой UEFI (OVMF).

Когда виртуальная машина создается с UEFI, libvirt выделяет ей отдельный файл энергонезависимой памяти (NVRAM) для хранения переменных загрузчика, ключей Secure Boot и настроек BIOS. Этот файл по умолчанию создается в формате Raw, а не QCOW2.

При попытке сделать внутренний снимок такой машины без флага --disk-only, libvirt попытается сохранить состояние не только диска vda, но и устройства NVRAM (которое представлено как pflash). Поскольку формат Raw не поддерживает внутренние снимки, команда завершится ошибкой вида: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported.

Решений у этой проблемы два. Первое — использовать исключительно внешние снимки с флагом --disk-only. Внешние снимки умеют работать с любыми блочными устройствами, замораживая их и создавая QCOW2-оверлеи. Второе решение — принудительно исключить устройство NVRAM из процесса создания снимка через редактирование XML-манифеста снимка, однако это лишает администратора возможности восстановить точное состояние загрузчика на момент создания среза. В корпоративной практике для UEFI-машин стандартом де-факто стало использование внешних disk-only снимков в связке с qemu-guest-agent.

Грамотное использование снимков требует дисциплины. Оставленный на несколько недель активный снимок на высоконагруженном сервере баз данных способен исчерпать свободное место в пуле /mnt/kvm-data, так как overlay-файл может вырасти до размеров оригинального диска. Снимки должны рассматриваться исключительно как транзакционный механизм: создал, выполнил рискованную операцию, проверил результат, немедленно удалил (или сделал commit). Стратегия долгосрочного хранения состояний системы должна строиться на базе инкрементального резервного копирования, а не на цепочках дисковых образов гипервизора.

Мониторинг производительности гипервизора и анализ утилизации ресурсов VM

Администратор получает критический алерт: транзакции в базе данных внутри виртуальной машины выполняются с огромной задержкой. Подключение к хосту на Fedora 44 и запуск утилиты top показывают, что физический сервер простаивает на 80%. При этом внутри самой виртуальной машины показатель Load Average превышает количество доступных ядер в несколько раз. Этот классический парадокс виртуализации возникает из-за того, что гостевая операционная система не имеет полного представления о физическом оборудовании, а стандартные утилиты хоста не умеют заглядывать внутрь процессов QEMU. Для реальной оценки производительности требуется специализированный инструментарий, способный анализировать взаимодействие между гипервизором KVM, процессом-эмулятором и гостевой системой.

Архитектура метрик в libvirt

В стеке KVM/QEMU каждая виртуальная машина представляет собой обычный процесс в пространстве пользователя хост-системы (обычно qemu-system-x86_64). Виртуальные процессоры (vCPU) — это потоки (threads) данного процесса, а оперативная память гостя выделяется как анонимная память процесса QEMU.

Демон libvirtd собирает статистику, опрашивая QEMU через протокол QMP (QEMU Machine Protocol) и считывая данные из файловой системы /proc хоста. Универсальным инструментом для получения этих данных выступает команда virsh domstats. Она возвращает метрики в формате «ключ-значение» и поддерживает фильтрацию по подсистемам.

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

virsh domstats --cpu --balloon --block --net fedora-srv-01

Вывод этой команды структурирован по блокам, каждый из которых требует специфической интерпретации.

Анализ процессорного времени и выявление Steal Time

Процессорные метрики в виртуализации кардинально отличаются от метрик физического сервера. Гостевая ОС считает, что монопольно владеет процессором, но гипервизор KVM постоянно снимает потоки vCPU с физических ядер (context switching) для обслуживания других виртуальных машин или процессов хоста.

Интерпретация virsh domstats --cpu

При запросе статистики CPU команда возвращает следующие ключевые параметры:

• cpu.time — общее время (в наносекундах), которое процесс QEMU провел на физическом процессоре.
• cpu.user — время выполнения инструкций в пространстве пользователя (user space).
• cpu.system — время выполнения системных вызовов в пространстве ядра хоста (kernel space).

Сама по себе цифра cpu.time бесполезна, так как это постоянно растущий счетчик. Для оценки загрузки необходимо вычислять дельту между двумя измерениями.

$$U_{cpu} = \frac{T_{time2} - T_{time1}}{T_{wall2} - T_{wall1} \times N_{vcpu}} \times 100\%$$

Где:

• $U_{cpu}$ — процент утилизации процессора виртуальной машиной.
• $T_{time2}$ и $T_{time1}$ — значения cpu.time (в наносекундах) при втором и первом измерениях.
• $T_{wall2}$ и $T_{wall1}$ — реальное (астрономическое) время на хосте в момент измерений (в наносекундах).
• $N_{vcpu}$ — количество виртуальных ядер, выделенных машине.

Если виртуальная машина с 4 vCPU полностью загрузит их на 100%, значение cpu.time за одну секунду реального времени увеличится на 4 секунды (4 000 000 000 наносекунд).

Steal Time: когда гипервизор «крадет» время

Главный враг производительности в плотно населенных виртуальных средах — CPU Steal Time. Это время, в течение которого виртуальный процессор был готов выполнять инструкции (имел задачи в очереди), но гипервизор не выделил ему квант времени на физическом ядре.

Внутри гостевой ОС (Linux) этот параметр виден в выводе top как %st. Если значение %st стабильно превышает 5-10%, виртуальная машина испытывает процессорное голодание.

На стороне хоста для анализа распределения vCPU по физическим ядрам используется команда virsh vcpuinfo:

virsh vcpuinfo fedora-srv-01

Вывод покажет, на каком именно физическом ядре (CPU) в данный момент выполняется каждый vCPU, и его CPU Affinity (маску привязки). Если в главе о создании машины была настроена жесткая привязка (CPU Pinning), маска будет выглядеть как ------y---------, разрешая выполнение только на конкретном ядре. Если привязки нет, маска yyyyyyyyyyyyyyyy означает, что планировщик ядра Linux может свободно перемещать поток vCPU по всем доступным физическим ядрам. Частая миграция потоков между NUMA-узлами приводит к сбросу кэшей L3 и резкому росту задержек.

Мониторинг утилизации памяти: RSS против Actual

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

Команда virsh dommemstat fedora-srv-01 предоставляет статистику, объединяющую взгляд хоста и гостя (если установлен qemu-guest-agent).

Ключевые метрики памяти:

• actual — объем памяти, выделенный виртуальной машине в конфигурации (например, 4096 Мб).
• available — общий объем памяти, видимый гостевой ОС.
• unused — объем памяти, который гостевая ОС считает абсолютно свободным (не занят даже кэшами).
• rss (Resident Set Size) — объем физической памяти хоста, реально потребляемый процессом QEMU.

Парадокс Resident Set Size (RSS)

Значение rss часто вызывает вопросы у администраторов, так как оно может быть больше, чем выделенная машине память (actual). Если машине выделено 4 Гб RAM, rss может достигать 4.2 Гб или 4.5 Гб.

Это нормальное поведение. В показатель rss входит не только оперативная память гостя, но и накладные расходы самого эмулятора QEMU:

• Память, выделенная под виртуальную видеокарту (QXL/VirtIO GPU).
• Буферы для эмуляции сетевых и дисковых устройств.
• Внутренние структуры данных гипервизора KVM.

С другой стороны, если используется механизм тонкого выделения памяти, rss может быть значительно меньше actual. Если гостевая ОС при загрузке коснулась только 1 Гб страниц памяти из выделенных 4 Гб, ядро хоста (Linux) физически выделит только 1 Гб.

Мониторинг своппинга

Самый критичный сценарий для производительности — попадание памяти виртуальной машины в раздел подкачки (swap) на хосте. В выводе dommemstat за это отвечают метрики swap_in и swap_out. Появление любых значений, отличных от нуля, в этих полях сигнализирует о жесткой нехватке RAM на сервере Fedora 44. Когда гостевая ОС пытается обратиться к странице памяти, которая была выгружена хостом в swap, происходит двойная задержка: сначала хост считывает страницу с диска, и только потом гость получает к ней доступ.

Анализ дисковой подсистемы и расчет задержек (Latency)

Дисковый ввод-вывод (I/O) — самое узкое место любой виртуальной инфраструктуры. В KVM статистика собирается на уровне блочного устройства, предоставляемого гостю.

Команда virsh domblkstat fedora-srv-01 vda выводит детальную статистику по диску vda:

• rd_req / wr_req — количество запросов на чтение и запись (IOPS).
• rd_bytes / wr_bytes — объем прочитанных и записанных данных в байтах (Throughput).
• rd_total_times / wr_total_times / flush_total_times — суммарное время (в наносекундах), затраченное на операции чтения, записи и сброса кэша на физический носитель.

Вычисление среднего размера блока

Зная количество запросов и объем данных, можно определить профиль нагрузки виртуальной машины (средний размер блока I/O):

$$B_{avg} = \frac{\Delta Bytes}{\Delta Req}$$

Где:

• $B_{avg}$ — средний размер блока в байтах.
• $\Delta Bytes$ — разница значений rd_bytes (или wr_bytes) между двумя измерениями.
• $\Delta Req$ — разница значений rd_req (или wr_req) между двумя измерениями.

Нагрузка с размером блока 4-8 Кб типична для баз данных и требует хранилищ с высоким показателем IOPS (NVMe). Нагрузка с блоками 1-4 Мб характерна для файловых серверов или потокового видео, где важнее линейная пропускная способность.

Расчет задержки (Latency)

Суммарное время выполнения операций позволяет вычислить среднюю задержку (latency) дисковой подсистемы — главный индикатор здоровья хранилища.

$$L_{avg} = \frac{\Delta T_{read} + \Delta T_{write} + \Delta T_{flush}}{\Delta R_{read} + \Delta R_{write} + \Delta R_{flush}} / 10^6$$

Где:

• $L_{avg}$ — средняя задержка на одну операцию в миллисекундах.
• $\Delta T$ — изменение суммарного времени выполнения операций (в наносекундах) за период.
• $\Delta R$ — изменение количества запросов за тот же период.
• Деление на $10^6$ конвертирует наносекунды в миллисекунды.

Если расчетный показатель $L_{avg}$ стабильно превышает 10-15 мс для SSD/NVMe пулов, это указывает на проблемы. Причинами могут быть:

1. Фрагментация образа QCOW2.
2. Нехватка пропускной способности интерфейса хоста.
3. Очередь блокировок (locking) на уровне файловой системы Btrfs (если не был применен атрибут +C, отключающий Copy-on-Write для директории образов).

Мониторинг сетевой активности и дропов на мосту

Сетевая статистика собирается для каждого виртуального интерфейса (vNIC). Команда virsh domifstat fedora-srv-01 vnet0 показывает счетчики принятых (rx_bytes) и отправленных (tx_bytes) данных, а также ошибки и отброшенные пакеты (rx_drop, tx_drop).

В контексте сетевого моста (Bridge) на интерфейсе enp2s0 появление отброшенных пакетов (rx_drop) на виртуальном интерфейсе vnet0 обычно означает переполнение кольцевого буфера (ring buffer) драйвера VirtIO. Это происходит, когда физический интерфейс хоста принимает трафик на скорости 10 Гбит/с, а виртуальная машина не успевает обрабатывать прерывания из-за нехватки процессорного времени (тот самый Steal Time) или отсутствия многоочередности (Multi-Queue VirtIO).

Интерактивный мониторинг через virt-top

Для наблюдения за метриками в реальном времени без необходимости вручную вычислять дельты используется утилита virt-top. Она написана на OCaml и использует API libvirt для агрегации данных, предоставляя интерфейс, аналогичный классическому top.

Запуск утилиты:

virt-top --delay 2

Интерфейс virt-top разделен на две части. В верхней отображается глобальная статистика хоста: общее количество машин, распределение состояний (Running, Paused, Shut off) и общая утилизация CPU/RAM. В нижней части — таблица с процессами виртуальных машин.

Ключевые столбцы virt-top:

• %CPU — процент использования физического процессора хоста. В отличие от стандартного top, где 100% — это одно ядро, в virt-top 100% может означать полную утилизацию всех выделенных vCPU.
• %MEM — процент физической оперативной памяти хоста, потребляемой доменом (на базе метрики RSS).
• TIME — суммарное процессорное время с момента запуска машины.

Для автоматизации сбора логов virt-top поддерживает пакетный режим (batch mode), который позволяет записывать метрики в CSV-файл для последующего анализа:

virt-top --batch --iterations 60 --delay 1 --csv /var/log/kvm/virt-top-stats.csv

Эта команда соберет 60 срезов статистики с интервалом в 1 секунду и сохранит их в файл.

Экспорт метрик для Time-Series систем (Telegraf)

Анализ через CLI-утилиты (virsh, virt-top) эффективен для расследования инцидентов в моменте (troubleshooting). Для проактивного мониторинга и ретроспективного анализа требуется сбор метрик в системы временных рядов (Time-Series Databases), такие как Prometheus или InfluxDB.

В экосистеме Linux стандартом де-факто для сбора системных метрик является агент Telegraf. Он содержит встроенный плагин inputs.libvirt, который автоматизирует процесс опроса libvirtd и избавляет администратора от необходимости писать bash-скрипты для парсинга virsh domstats.

Пример конфигурации плагина в /etc/telegraf/telegraf.d/libvirt.conf:

[[inputs.libvirt]]
  ## URI для подключения к демону libvirt
  libvirt_url = "qemu:///system"

  ## Какие метрики собирать (соответствует флагам domstats)
  gather_cpu = true
  gather_memory = true
  gather_block = true
  gather_network = true

  ## Фильтрация по состояниям (собирать метрики только с работающих машин)
  domain_state_filter = ["running"]

Плагин подключается к сокету qemu:///system и с заданной частотой (обычно раз в 10 секунд) снимает показания счетчиков. Важное преимущество такого подхода — Telegraf самостоятельно вычисляет дельты для растущих счетчиков (таких как cpu.time или rd_bytes) с помощью функции derivative, отправляя в базу данных готовые значения IOPS, пропускной способности и утилизации CPU в процентах.

Понимание того, как метрики формируются на стыке эмулятора QEMU, гипервизора KVM и ядра Linux, позволяет точно локализовать узкие места. Администратор, вооруженный знанием о природе Steal Time, механике расчета задержек блочных устройств и специфике показателя RSS, способен отличить реальную деградацию производительности гостевой ОС от штатной работы механизмов оптимизации ресурсов хоста.

Графическое администрирование и централизованное управление через веб-интерфейс Cockpit

Представьте ситуацию: вы находитесь в дороге, у вас под рукой только планшет или чужой ноутбук, а на одном из серверов Fedora 44 в дата-центре критически не хватает ресурсов для виртуальной машины. Запускать SSH-клиент, пробрасывать туннели для SPICE и вспоминать точный синтаксис virsh setmem в таких условиях — задача не из приятных. Именно здесь на сцену выходит Cockpit — современный, легкий и невероятно мощный инструмент, который превращает управление KVM из «консольной магии» в интуитивно понятный визуальный процесс, доступный через обычный браузер.

Философия Cockpit: почему это не «очередная панель управления»

В отличие от тяжеловесных решений вроде oVirt или OpenStack, Cockpit не является абстрактным слоем над операционной системой. Он придерживается принципа «Interacts with the OS, not replaces it». Это означает, что если вы измените конфигурацию сети через nmcli или создадите виртуальную машину через virt-install, Cockpit мгновенно отобразит эти изменения. Он не хранит собственную базу данных состояний, а напрямую обращается к системным API — systemd, NetworkManager, libvirtd и dbus.

Для администратора KVM это дает три ключевых преимущества:

1. Нулевое влияние на производительность в простое: если вкладка браузера закрыта, Cockpit практически не потребляет ресурсов хоста.
2. Прозрачность: действия в графическом интерфейсе транслируются в стандартные системные вызовы.
3. Безопасность: используется системная аутентификация (PAM), а привилегии соответствуют правам пользователя (sudo).

Развертывание и активация графического стека на Fedora 44

В Fedora 44 Cockpit часто предустановлен в минимальной конфигурации, но для полноценного управления виртуализацией нам потребуется специализированный плагин cockpit-machines.

Установка выполняется одной командой, которая подтягивает необходимые зависимости для визуализации графиков и управления хранилищами:

sudo dnf install -y cockpit cockpit-machines cockpit-networkmanager cockpit-storaged

После установки необходимо активировать сокет. Мы используем именно socket activation, чтобы служба запускалась только при поступлении запроса на порт 9090:

sudo systemctl enable --now cockpit.socket

Проверьте доступность порта в firewalld. По умолчанию Fedora разрешает сервис cockpit в зоне fedora-workstation, но на серверных редакциях это может потребоваться сделать вручную:

sudo firewall-cmd --add-service=cockpit --permanent
sudo firewall-cmd --reload

Теперь, перейдя по адресу https://<IP-вашего-сервера>:9090, вы попадете в интерфейс управления. Важно помнить, что Cockpit использует самоподписанный сертификат. В корпоративной среде хорошим тоном будет заменить его на сертификат от вашего CA или Let's Encrypt, разместив файлы .cert и .key в директории /etc/cockpit/ws-certs.d/.

Визуализация виртуальной инфраструктуры

Раздел «Виртуальные машины» (Machines) в Cockpit — это полноценная графическая надстройка над libvirt. При входе в этот раздел система автоматически подключается к qemu:///system.

Обзор состояния хоста

Первое, что видит администратор — это сводная панель ресурсов. Здесь Cockpit агрегирует данные, которые мы ранее учились собирать через virsh domstats и virt-top. Однако визуализация позволяет заметить аномалии быстрее:

• Графики CPU и Memory: показывают суммарное потребление всеми доменами. Если вы видите, что полоса памяти заполнена на 90%, а внутри VM используется лишь 30%, это явный сигнал проверить настройки ballooning или HugePages, о которых мы говорили в прошлых главах.
• Статус хранилищ: Cockpit подсвечивает пулы, в которых заканчивается место. Это критично для QCOW2-образов с тонким выделением (sparse files), так как переполнение физического раздела приведет к мгновенной остановке всех VM в состоянии paused (IO error).

Управление жизненным циклом одной кнопкой

Интерфейс позволяет выполнять все операции, изученные в главе 6:

• Запуск/Выключение: Cockpit корректно посылает сигнал SIGTERM через ACPI или использует qemu-guest-agent, если он установлен.
• Пауза и Managed Save: одним кликом можно перевести машину в состояние сохранения состояния на диск, что освободит оперативную память хоста.
• Автозапуск: переключатель "Autostart" создает ту самую символическую ссылку в /etc/libvirt/qemu/autostart/, которую мы раньше создавали вручную.

Глубокая настройка оборудования через браузер

Одной из самых мощных функций cockpit-machines является возможность редактирования состава оборудования без прямого написания XML.

Редактирование vCPU и RAM

Вы можете изменять количество ядер и объем памяти «на лету». Если в конфигурации VM включена возможность горячей замены (Hotplug), Cockpit позволит увеличить объем RAM без перезагрузки.

Важно: Уменьшение объема памяти почти всегда требует перезагрузки гостевой ОС, так как механизмы ядра Linux (memory ballooning) не всегда могут корректно вернуть страницы памяти хосту без риска для стабильности приложений.

Конфигурация дисков и сетевых интерфейсов

В подразделе "Disks" можно не только добавлять новые диски, но и изменять их тип шины (VirtIO, SATA, SCSI). Здесь же доступна опция "Resize", которая расширяет QCOW2-файл. После этого вам останется только зайти в консоль гостя и расширить файловую систему (например, через xfs_growfs или resize2fs).

В разделе "Networks" Cockpit позволяет переключать интерфейсы между различными мостами. Если вы настроили мост br0 на интерфейсе enp2s0 (как мы делали во второй главе), он будет доступен в выпадающем списке. Вы также можете изменить модель сетевого адаптера на virtio для максимальной производительности.

Работа с консолью и протоколом SPICE

Cockpit решает одну из самых больших проблем удаленного администрирования — доступ к графическому выводу VM без настройки сложных туннелей.

Встроенный VNC/SPICE клиент

Вкладка "Console" внутри выбранной VM предоставляет доступ к экрану через протокол VNC или SPICE, инкапсулированный в WebSocket. Это означает, что вы видите процесс загрузки BIOS/UEFI, меню GRUB и графический установщик ОС прямо в окне браузера.

• Преимущество: Не нужно устанавливать virt-viewer на локальный компьютер.
• Ограничение: Производительность отрисовки в браузере через WebSocket ниже, чем у нативного клиента. Для работы с тяжелой графикой лучше использовать SSH-туннель и remote-viewer, но для системного администрирования возможностей Cockpit более чем достаточно.

Текстовая консоль (Serial Console)

Если в Domain XML настроен последовательный порт (Serial PTY), Cockpit позволит переключиться на текстовую консоль. Это незаменимо, если вы случайно заблокировали доступ по SSH через firewalld внутри гостевой системы.

Продвинутые операции: Снимки и USB

Cockpit значительно упрощает работу с механизмом снимков (snapshots), который мы детально разбирали в главе 8.

Визуальное управление снимками

Вместо того чтобы отслеживать цепочки backing-файлов в консоли, вы видите список снимков с датами их создания.

1. Создание: При нажатии "Create Snapshot" Cockpit позволяет задать имя и описание. Если qemu-guest-agent активен, система автоматически применит флаг --quiesce для заморозки файловой системы, обеспечивая консистентность данных.
2. Восстановление: Выбор снимка и нажатие "Revert" вернет машину в предыдущее состояние.

Внимание: Cockpit в текущих версиях Fedora 44 лучше всего работает с внутренними снимками QCOW2. Если вы используете сложные внешние цепочки, созданные вручную, интерфейс может отображать их с ограничениями.

Проброс USB-устройств

Помните мучительный поиск Vendor ID и Product ID через lsusb? В Cockpit проброс USB превращается в выбор устройства из списка. При нажатии "Add Hardware" -> "USB Device" система сканирует шину хоста и предлагает список подключенных физических устройств. Cockpit сам сформирует нужный XML-фрагмент и выполнит virsh attach-device --live --config, обеспечив сохранение проброса после перезагрузки.

Мониторинг и диагностика через Cockpit

Раздел "Metrics" (если установлен пакет cockpit-pcp) предоставляет глубокую аналитику, дополняющую возможности virt-top.

Анализ нагрузки

Cockpit позволяет сопоставить всплески нагрузки на хосте с конкретными процессами qemu-system-x86_64. Если одна из виртуальных машин начинает «штормить» диск (I/O Wait), вы увидите это на графике дисковой активности хоста и сможете мгновенно идентифицировать виновника в списке Machines.

Просмотр логов

Интеграция с journald позволяет фильтровать логи именно по конкретной виртуальной машине. Если VM не запускается из-за ошибки в конфигурации или проблем с правами доступа SELinux к образу диска, соответствующие записи появятся в подразделе "Logs" данной машины. Это избавляет от необходимости вручную вычищать /var/log/libvirt/qemu/vm-name.log.

Централизованное управление: Мультихостовость

Одна из самых недооцененных функций Cockpit — это возможность управлять целым парком серверов из одной панели. Вам не нужно устанавливать Cockpit на каждый сервер как полноценный веб-сервер. Достаточно иметь один «мастер-узел».

На боковой панели можно нажать "Add New Host". Cockpit подключится к удаленному серверу по SSH (используя ваши ключи или пароль) и пробросит интерфейс управления. Таким образом, вы можете переключаться между сервером в Москве и сервером в Новосибирске в один клик, управляя всеми виртуальными машинами в едином стиле.

Для администратора это означает:

• Единую точку входа.
• Возможность визуального сравнения конфигураций разных гипервизоров.
• Удобство миграции (хотя полноценная Live Migration в Cockpit пока требует ручной подготовки инфраструктуры, визуальный контроль за процессом на обоих узлах бесценен).

Безопасность и разграничение доступа

Поскольку Cockpit работает от имени системного пользователя, безопасность строится на базе стандартных механизмов Linux.

• Sudo: Если пользователь, под которым вы вошли в Cockpit, имеет право на sudo, в верхней части интерфейса появится кнопка "Administrative Access". Только после её нажатия и подтверждения пароля вы сможете изменять конфигурацию VM. В режиме "Limited Access" доступен только просмотр.
• SELinux: Все действия, инициируемые через Cockpit, проходят проверку политиками SELinux. Если вы попытаетесь подключить ISO-образ из директории, не имеющей контекста virt_content_t, система выдаст ошибку, а в разделе "SELinux" появится предложение исправить контекст (кнопка "Apply Solution"). Это делает Cockpit отличным инструментом для обучения правильной работе с безопасностью в Fedora.

Оптимизация Cockpit для больших инсталляций

Если у вас на одном хосте запущены десятки виртуальных машин, стандартный вид списка может стать неудобным. В Fedora 44 интерфейс cockpit-machines поддерживает фильтрацию и поиск по именам.

Также стоит обратить внимание на настройки обновления данных. По умолчанию Cockpit опрашивает систему довольно часто. Если канал связи с сервером узкий (например, спутниковая связь или перегруженный 4G), можно настроить интервалы обновления в файле /etc/cockpit/cockpit.conf:

[WebService]
IdleTimeout=15

Это завершит сессию при неактивности, экономя трафик и ресурсы сервера.

Сравнение: CLI vs Cockpit

Несмотря на удобство графики, важно понимать границы применимости инструментов.

Задача	Инструмент (CLI)	Инструмент (Cockpit)	Комментарий
Массовое создание 100 VM	Скрипт на bash + virt-install	Неудобно (по одной)	CLI выигрывает в автоматизации
Быстрая диагностика I/O Wait	iostat, virt-top	Графики в реальном времени	Cockpit нагляднее для поиска аномалий
Исправление ошибок загрузки	virsh console	Вкладка "Console"	Равнозначно, но Cockpit доступен из браузера
Сложный проброс PCI-устройств	Редактирование XML	Ограниченная поддержка	Для специфичного HW нужен CLI
Управление снимками	virsh snapshot-create-as	Кнопка "Create Snapshot"	Cockpit снижает риск ошибки в синтаксисе

Cockpit не заменяет знания, полученные вами в предыдущих девяти главах, но он делает их применение более эффективным. Он берет на себя рутину по формированию XML и визуализации данных, оставляя администратору принятие архитектурных решений.

Использование Cockpit на Fedora 44 — это «золотой стандарт» для современного администратора. Это мост между классическим Unix-подходом и современными требованиями к скорости и доступности управления. Завершая этот курс, вы теперь обладаете полным арсеналом: от низкоуровневой настройки ядра и сетевых мостов до высокоуровневого управления всей инфраструктурой через элегантный веб-интерфейс.