QEMU - это рабочая лошадка под почти всеми гипервизорами Linux, которые вы видели: и libvirt, и облачные стенды, и тестовые виртуалки в CI запускают именно qemu-system. Задача этого урока - научиться запускать виртуальную машину голой командой qemu-system, понимать, чем эмуляция отличается от аппаратного ускорения KVM, и осознанно собирать модель устройств (virtio), управлять памятью и процессором, делать снимки и пробрасывать железо. Когда вы понимаете слой QEMU напрямую, вы перестаёте бояться XML libvirt - он всего лишь генерирует ту же командную строку.
Как это работает
QEMU сам по себе - чистый эмулятор. Он умеет программно изображать целый компьютер: процессор чужой архитектуры, чипсет, шины, диски, сетевые карты. Эмуляция универсальна (можно запустить ARM на x86), но медленна, потому что каждую инструкцию гостя QEMU транслирует в инструкции хоста через свой движок TCG (Tiny Code Generator).
KVM - это модуль ядра Linux (kvm.ko плюс kvm-intel.ko или kvm-amd.ko), который превращает процессор в гипервизор через расширения Intel VT-x или AMD-V. Когда архитектура гостя совпадает с хостом, QEMU отдаёт исполнение инструкций напрямую железу, а сам остаётся только в роли эмулятора устройств ввода-вывода и менеджера машины. Отсюда правило: QEMU - это устройства и оркестровка, KVM - это быстрый CPU. Признак работы KVM - устройство /dev/kvm и опция -accel kvm (или -enable-kvm).
Ключевая идея производительности - паравиртуализация virtio. Эмулировать реальную сетевую карту Intel e1000 дорого: гость думает, что пишет в регистры железа, и каждый доступ ловится гипервизором. Драйверы virtio устроены иначе - гость заранее знает, что он виртуален, и общается с хостом через кольцевые буферы в общей памяти (virtqueue). Это убирает массу лишних выходов в гипервизор. Поэтому диски делают virtio-blk или virtio-scsi, сеть - virtio-net, а память можно отдавать обратно через virtio-balloon.
QEMU-машина управляется через мониторы. HMP (human monitor) - текстовый интерактивный интерфейс для человека (info block, savevm). QMP - это JSON-протокол, через который с QEMU разговаривает libvirt и автоматика. Снимки бывают двух видов: внутренние (savevm, живут внутри qcow2, требуют формата qcow2) и внешние (отдельный overlay-файл поверх базового). Снимок состояния с памятью даёт мгновенный откат живой машины, снимок только диска - точку для бэкапа.
Команды и примеры
Установка пакетов отличается по семействам.
Код: Выделить всё
# Debian 13 / Ubuntu 24.04 LTS
sudo apt install qemu-system-x86 qemu-utils
# RHEL 10 / Fedora 41+
sudo dnf install qemu-kvm qemu-img
Код: Выделить всё
# поддержка VT-x/AMD-V процессором
grep -E -o 'vmx|svm' /proc/cpuinfo | sort -u
# модули и устройство
lsmod | grep kvm
ls -l /dev/kvm
Код: Выделить всё
qemu-img create -f qcow2 disk.qcow2 20G
qemu-system-x86_64 \
-machine q35,accel=kvm \
-cpu host -smp 4 -m 4G \
-drive file=disk.qcow2,if=virtio,format=qcow2 \
-cdrom debian-13.iso \
-netdev user,id=n0,hostfwd=tcp::2222-:22 \
-device virtio-net-pci,netdev=n0 \
-nographic
Войти в монитор из -nographic можно сочетанием Ctrl-a c (переключение консоль/монитор), Ctrl-a x - выход. Снимки внутри qcow2:
Код: Выделить всё
# из HMP-монитора живой машины
(qemu) savevm snap1
(qemu) info snapshots
(qemu) loadvm snap1
# офлайн, утилитой
qemu-img snapshot -l disk.qcow2
qemu-img snapshot -c snap2 disk.qcow2
Код: Выделить всё
qemu-img create -f qcow2 -b base.qcow2 -F qcow2 overlay.qcow2
Код: Выделить всё
-device vfio-pci,host=0000:01:00.0
Код: Выделить всё
virsh domxml-to-native qemu-argv --domain myvm
- Машина запустилась, но тормозит как улитка - значит KVM не подхватился и работает чистый TCG. Проверьте /dev/kvm, права (группа kvm), и что в BIOS/UEFI включена виртуализация. Добавляйте accel=kvm и не надейтесь на дефолт.
- Гость не видит диск или сеть при -if=virtio - в установщике или ядре нет драйверов virtio. Старые или нестандартные ОС лечатся переключением на if=ide / -device e1000, либо подгрузкой virtio-драйверов.
- savevm падает с ошибкой - внутренние снимки требуют qcow2 для ВСЕХ дисков машины. На raw или на проброшенном блочном устройстве внутренний снимок невозможен.
- -cpu host ломает живую миграцию между разными моделями процессоров. Для кластера фиксируйте именованную модель или baseline.
- Запуск qemu-system из-под обычного пользователя для tap-сети и VFIO упирается в права. libvirt решает это через отдельного пользователя qemu и polkit - вручную нужны capabilities или root.
- Путаница i440fx и q35: на старом i440fx нет нормального PCIe, проброс устройств и горячее подключение работают хуже. По умолчанию сейчас берут q35.
- Установите qemu-system-x86 / qemu-kvm и проверьте наличие /dev/kvm и флага vmx или svm.
- Создайте qcow2-диск на 20G и поднимите гостя из ISO с machine q35,accel=kvm, -cpu host, virtio-диском и virtio-net, проброс порта 2222 на 22.
- Завершите установку гостя, зайдите по ssh -p 2222 на localhost.
- Войдите в HMP-монитор (Ctrl-a c), выполните info block и info kvm, убедитесь, что ускорение активно.
- Сделайте внутренний снимок savevm clean, измените что-нибудь в госте, затем откатитесь через loadvm clean.
- Создайте внешний overlay поверх базового диска и запустите гостя уже с overlay, проверив, что база не меняется.
- Дополнительно: опишите ту же машину в libvirt и сравните вывод virsh domxml-to-native qemu-argv со своей командной строкой.
- В чём принципиальная разница ролей QEMU и KVM при запуске x86-гостя на x86-хосте, и какой признак говорит, что KVM реально используется?
- Почему virtio-устройства быстрее эмуляции реальной карты, и через какой механизм гость и хост обмениваются данными?
- Когда вы выберете -cpu host, а когда именованную модель CPU, и какое ограничение накладывает первый вариант?
- Чем внутренний снимок qcow2 отличается от внешнего overlay, и какие требования у каждого из них?
- Какие шаги нужны, чтобы пробросить PCI-устройство в гостя, и какая подсистема ядра за это отвечает?
- Чем машина q35 предпочтительнее i440fx и в каких случаях ещё берут i440fx?
