1. Подготовка сервера и установка стека виртуализации 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.
В этом выводе нас интересуют два ключевых значения:
vmx — для процессоров Intel.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:
После обновления ядра обязательно перезагрузите сервер. KVM жестко завязан на версии модулей ядра, и попытка инициализировать гипервизор на старом ядре при наличии обновленного в системе может вызвать трудноотлаживаемые ошибки.
Настройка параметров ядра (Kernel Boot Parameters)
Для стабильной работы гипервизора, особенно если планируется работа с большими объемами памяти или пробросом устройств, рекомендуется добавить параметры инициализации IOMMU в загрузчик GRUB.
Отредактируйте файл /etc/default/grub. Найдите строку GRUB_CMDLINE_LINUX и добавьте в неё:
intel_iommu=on iommu=ptamd_iommu=on iommu=ptПараметр iommu=pt (pass-through) критически важен: он предотвращает попытки ядра Linux затронуть устройства, которые не используются хостом, что улучшает производительность ввода-вывода.
После внесения изменений обновите конфигурацию GRUB:
Установка программного стека виртуализации
В Fedora 44 процесс установки максимально упрощен благодаря группам пакетов. Нам не нужно собирать зависимости вручную; достаточно использовать мета-пакеты, которые подтянут всё необходимое: от самого эмулятора до инструментов управления.
Основные компоненты
Выполните команду установки:
Символ @ указывает DNF, что нужно установить группу пакетов «Virtualization». В неё входят:
qemu-kvm: Основной пакет, обеспечивающий аппаратное ускорение.libvirt: API и демон (libvirtd) для управления виртуализацией.virt-install: Утилита командной строки для создания новых VM.virt-viewer: Инструмент для графического подключения к консоли (через SPICE/VNC).libvirt-client: Набор клиентских утилит, включая virsh.Помимо группы, нам потребуются дополнительные инструменты для работы с дисками и сетевой настройки, которые могут не входить в базовую группу:
virt-manager: Хотя мы работаем удаленно, наличие этого GUI-инструмента полезно, если вы планируете использовать X11 Forwarding.libguestfs-tools: Мощнейший набор утилит для модификации образов дисков виртуальных машин без их запуска (например, virt-customize или virt-df).Активация и настройка демона libvirtd
После установки пакетов система еще не готова к работе. Демон libvirtd, который является «мозгом» нашей инфраструктуры, по умолчанию может быть не запущен.
В современных дистрибутивах на базе Fedora/RHEL используется модульный подход к libvirtd. Вместо одного монолитного демона запускаются отдельные сервисы для управления сетями, хранилищами и интерфейсами. Однако для простоты администрирования на начальном этапе мы будем использовать основной сервис.
Активируем и запускаем службу:
Проверьте статус службы, чтобы убедиться в отсутствии ошибок при инициализации модулей ядра:
Если вы видите active (running), значит, KVM успешно подгрузил модули kvm_intel или kvm_amd. Вы можете подтвердить это командой:
Разграничение прав доступа
Работа под учетной записью root — плохая практика. Для повседневного управления виртуальными машинами через SSH нам нужно настроить права доступа для обычного пользователя.
В Fedora группа libvirt обладает правами на управление гипервизором. Добавьте вашего текущего пользователя в эту группу:
Чтобы изменения вступили в силу без перезагрузки, выполните:
Теперь вы можете выполнять команды управления (например, virsh list --all) без префикса sudo. Это не только вопрос безопасности, но и удобства: многие инструменты (например, Cockpit или графические клиенты) ожидают именно такого способа аутентификации.
Тонкая настройка конфигурации libvirt
Файл /etc/libvirt/libvirtd.conf содержит настройки демона. Для удаленного администрирования через SSH нам обычно не требуется менять настройки прослушивания портов (так как SSH обеспечивает туннелирование), но есть параметры, которые стоит проверить.
Особое внимание уделите механизмам блокировки дисков. Если в будущем вы планируете использовать общее хранилище для нескольких гипервизоров, вам понадобится virtlockd. В рамках одного сервера убедитесь, что лимиты на количество открытых файлов достаточно высоки, так как каждая виртуальная машина — это процесс QEMU, открывающий множество дескрипторов (образы дисков, логи, каналы связи).
Проверка готовности: virt-host-validate
Теперь, когда стек установлен и запущен, пришло время финальной проверки. Утилита virt-host-validate просканирует состояние хоста и укажет на возможные проблемы.
Типичный вывод должен содержать PASS по всем критическим пунктам:
Если вы видите WARN напротив IOMMU, это не критично для запуска VM, но ограничит вас в будущем при попытке пробросить физическую видеокарту или сетевой адаптер внутрь гостя. Если же FAIL стоит напротив /dev/kvm, значит, модули ядра не загружены — проверьте настройки BIOS еще раз.
Оптимизация производительности хоста
Гипервизор — это система, которая должна отдавать максимум ресурсов гостям. Fedora по умолчанию настроена как универсальная ОС, что не всегда оптимально для KVM.
Профили электропитания (tuned)
Установите и активируйте сервис tuned, который автоматически оптимизирует параметры ядра под конкретную задачу:
Для гипервизора оптимальным профилем является virtual-host. Он настраивает планировщик задач процессора и параметры кэширования так, чтобы минимизировать задержки (latency) при переключении контекста между виртуальными машинами.
Проверить активный профиль можно командой 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 или получить доступ к критическим файлам хоста, так как метки не совпадут.
Для проверки статуса выполните:
Должно быть Enforcing. Если по какой-то причине вы видите Disabled, верните его в /etc/selinux/config и перезагрузитесь.
Настройка Firewalld
Для удаленного управления и работы сетевых мостов необходимо разрешить соответствующие сервисы в межсетевом экране.
Это позволит корректно работать протоколам управления. Если вы планируете использовать графический интерфейс Cockpit (который мы разберем в финале курса), добавьте и его:
Подготовка структуры каталогов
По умолчанию Libvirt хранит образы дисков в /var/lib/libvirt/images. Однако в реальных серверных сценариях под данные виртуальных машин часто выделяют отдельные дисковые массивы или разделы, смонтированные в другие точки.
Согласно нашему плану, мы будем использовать директорию /mnt/kvm-data. Создадим её заранее и установим правильные права доступа, чтобы Libvirt мог с ней работать:
Важно помнить о контексте SELinux для нестандартных директорий. Если просто создать папку, Libvirt не сможет запустить в ней диск из-за запрета системы безопасности. Назначим правильный тип контекста:
Здесь тип 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:
Этот модуль позволяет передавать сетевые пакеты между гостем и хостом практически на скорости физического интерфейса, минуя значительную часть накладных расходов в пространстве пользователя. Если он загружен — ваш сервер готов к высокопроизводительному сетевому обмену.
Также убедитесь, что включен IP Forwarding, так как гипервизор по сути является маршрутизатором для своих виртуальных машин:
Если значение равно 0, временно включите его (Libvirt обычно делает это сам при создании сетей, но лучше контролировать процесс):
Завершение этапа подготовки
На данный момент наш сервер на Fedora 44 полностью готов к работе в качестве гипервизора. Мы не просто установили пакеты, а подготовили почву:
tuned.Впереди — настройка сетевой инфраструктуры. Нам предстоит превратить физический интерфейс enp2s0 в сетевой мост, который позволит виртуальным машинам стать полноправными участниками вашей локальной сети, получать IP-адреса по DHCP и быть доступными извне так же, как и физические серверы. Но прежде чем переходить к сетям, убедитесь, что команда virsh uri возвращает qemu:///system — это подтверждение того, что ваш клиент настроен на работу с системным гипервизором.