Xen - это гипервизор первого типа (bare-metal), который грузится раньше любого ядра Linux и сам распределяет процессор и память между виртуальными машинами. Его особенность в том, что управляющая ОС (dom0) и гипервизор - это разные сущности: микроядро Xen занимается только планированием и изоляцией, а вся работа с дисками, сетью и драйверами выполняется в обычном Linux. На экзамене 305-300 от вас ждут понимания этой архитектуры, типов доменов PV/HVM/PVH, управления через xl и устройства xenstore. В этом уроке разберём, как поднять стенд, запустить и мигрировать гость, и где Xen в 2026 году ещё реально живёт.
Как это работает
После загрузчика управление получает не ядро Linux, а сам гипервизор Xen - крошечный слой, который видит всё железо. Затем Xen стартует привилегированный домен dom0: это полноценный Linux с особыми правами. Только dom0 (или назначенный driver domain) имеет доступ к физическим устройствам и через бэкенд-драйверы обслуживает остальные гости. Гости называются domU (unprivileged domain), и каждый из них общается с железом не напрямую, а через фронтенд-драйверы, которые ходят в dom0.
Изначально Xen прославился паравиртуализацией (PV): гостевое ядро знало, что работает под гипервизором, и вместо привилегированных инструкций делало гиперколлы. Это давало скорость без аппаратной виртуализации, но требовало правленого ядра и плохо дружило с современным железом (нет настоящих таблиц страниц, проблемы с безопасностью спекулятивных атак). Поэтому классический 32-битный PV сегодня считается легаси.
Сейчас актуальны два режима. HVM (Hardware Virtual Machine) использует Intel VT-x или AMD-V, эмулирует целый ПК через QEMU (BIOS/UEFI, диск, сеть) и запускает немодифицированную ОС, включая Windows. PVH (paravirtualized hardware) - современный компромисс: аппаратная виртуализация процессора и памяти, но без эмуляции устройств QEMU, ввод-вывод идёт через лёгкие PV-драйверы. PVH грузится быстро, имеет минимальную поверхность атаки и в 2026 году считается предпочтительным для Linux-гостей. На x86 исторический дефолт - PV, на Arm дефолт - PVH.
Связку фронтенд-бэкенд координирует xenstore - небольшая иерархическая база ключ-значение в памяти, общая для всех доменов. Через неё домены обмениваются параметрами устройств, путями к кольцевым буферам и статусами. Драйверы делают watch на ветки xenstore и реагируют на изменения - так гость узнаёт, что появился диск, а dom0 узнаёт, что гость запросил подключение.
Команды и примеры
Установка гипервизора и тулстека. На Debian 13 / Ubuntu 24.04:
Код: Выделить всё
apt update
apt install xen-hypervisor-amd64 xen-tools xen-utils
# после установки выбрать ядро Xen в grub и перезагрузиться
Код: Выделить всё
dnf install xen xen-hypervisor xen-runtime
systemctl enable --now xenstored xenconsoled
grub2-mkconfig -o /boot/grub2/grub.cfg
Код: Выделить всё
xl info # версия Xen, объём памяти, число CPU, флаги hvm
xl list # список доменов; Domain-0 всегда первый
xl dmesg # лог самого гипервизора (не dmesg ядра)
Код: Выделить всё
type = "pvh"
name = "web1"
memory = 2048
vcpus = 2
kernel = "/var/lib/xen/vmlinuz-deb13"
ramdisk = "/var/lib/xen/initrd-deb13.img"
cmdline = "root=/dev/xvda1 console=hvc0"
disk = [ "/var/lib/xen/web1.img,raw,xvda,rw" ]
vif = [ "bridge=xenbr0" ]
Запуск, консоль, жизненный цикл:
Код: Выделить всё
xl create /etc/xen/web1.cfg # создать и запустить домен
xl create -c /etc/xen/web1.cfg # сразу подцепиться к консоли
xl console web1 # подключиться к консоли (выход: Ctrl+])
xl pause web1 / xl unpause web1
xl shutdown web1 # корректное завершение через ACPI/PV
xl destroy web1 # жёстко убить (аналог выдернуть питание)
Код: Выделить всё
xenstore-ls /local/domain/0 # ветка dom0
xenstore-list /local/domain
xenstore-read /local/domain/1/name
Код: Выделить всё
# на стороне-приёмнике один раз разрешаем приём
xl migrate-receive # обычно поднимается сервисом, явно не запускают
# на источнике
xl migrate web1 dom0-host2.local # live по умолчанию
xl migrate --debug web1 dom0-host2 # с диагностикой
- Забыли выбрать в GRUB ядро через Xen - система грузится в обычный Linux, и xl выдаёт ошибку соединения с гипервизором. Проверяйте, что в xl info есть строка с версией Xen.
- Память dom0 не зафиксирована: по умолчанию dom0 балунит и отдаёт RAM гостям, что мешает планировщику. Задавайте dom0_mem=4G,max:4G в строке Xen в GRUB.
- Путаница type и builder: старые конфиги с builder="hvm" ещё работают, но опция помечена deprecated, на свежих сборках лучше сразу писать type.
- Пытаетесь запустить чистый 32-битный PV-гость на новом железе с включёнными митигациями - может не стартовать. Берите PVH или HVM.
- Миграция падает из-за разных моделей CPU или отсутствия общего диска - xl переносит только RAM и состояние, но не данные диска.
- Перепутали xl dmesg (лог гипервизора) и dmesg (лог ядра dom0) - ищете сообщение Xen не там.
- Установите Xen-гипервизор на свой стенд (Debian 13 или Fedora) и перезагрузитесь в ядро через Xen.
- Командой xl info и xl list убедитесь, что dom0 живой; найдите в выводе число доступных vcpu.
- Создайте образ диска через truncate или dd на 4 ГБ и разверните в него минимальную систему (debootstrap или готовый cloud-образ).
- Напишите конфиг PVH-гостя по примеру выше и поднимите его через xl create -c, дождитесь приглашения логина.
- Из dom0 посмотрите ветку гостя в xenstore: xenstore-ls /local/domain/1.
- Сделайте xl pause, проверьте статус в xl list (флаг p), затем xl unpause.
- Если есть второй хост - настройте общий storage и выполните xl migrate, наблюдая за доменом на приёмнике.
- Чем принципиально отличается роль гипервизора Xen от роли dom0 и почему их разделяют?
- В чём разница между PV, HVM и PVH по способу работы с процессором и устройствами ввода-вывода?
- Какую функцию выполняет xenstore и как через него взаимодействуют фронтенд- и бэкенд-драйверы?
- Какой конфигурационный ключ пришёл на смену builder и какие значения он принимает?
- Что переносит xl migrate при живой миграции, а что должно быть обеспечено заранее?
- Почему классический 32-битный PV сегодня считается легаси и чем его заменяют?
