QEMU: мощный эмулятор процессоров для серверной инфраструктуры

QEMU - открытый эмулятор процессоров и по совместительству гипервизор. Он делает две непохожие вещи. Первая: запускает код, собранный под одну процессорную архитектуру, на машине с совершенно другой - ARM-систему на Xeon, RISC-V на EPYC, старую MIPS-прошивку роутера на обычном рабочем ноутбуке. Вторая: в связке с модулем ядра KVM перестаёт эмулировать процессор и отдаёт гостевую систему прямо физическим ядрам, теряя на этом считаные проценты скорости. Первый режим медленный и всеядный, второй быстрый и привязан к архитектуре хоста.

Отсюда и типичный сценарий. Приложение нужно проверить на ARM, а все серверы в стойке - на Intel Xeon. Покупать отдельное железо ради тестов дорого, арендовать облачную машину для регулярных прогонов неудобно. QEMU закрывает эту дыру: одна команда, и на x86-хосте поднимается ARM-машина. Медленно, но честно.

Проект появился в 2003 году, автор - французский программист Fabrice Bellard, тот самый, что сделал FFmpeg. За двадцать с лишним лет QEMU оброс поддержкой Red Hat и IBM и стал фундаментом почти всей Linux-виртуализации: Proxmox, oVirt, российские платформы - под капотом у всех он. Актуальная версия - 11.1.0 от 11 августа 2026: 3 200 с лишним коммитов от 285 участников, вложенная виртуализация для ARM, горячее подключение NVMe-неймспейсов через QMP и закрытые уязвимости в virtio, 9pfs и NVMe.

Эмуляция или виртуализация? Вот в чем вопрос

Тут начинается самое интересное. QEMU работает в двух режимах, и разница между ними принципиальная.

Полная эмуляция через TCG (Tiny Code Generator) - это когда QEMU берет инструкции одной архитектуры и на лету переводит их в инструкции другой. Запустить ARM-код на x86? Легко. MIPS на PowerPC? Тоже. Работает динамическая трансляция: QEMU разбирает входящий поток инструкций, оптимизирует его и генерирует код под архитектуру вашего хоста. Плата за универсальность - скорость. Насколько именно просядет, зависит от того, что вы гоняете: на простой целочисленной логике потери в разы, на плавающей точке и векторных инструкциях могут дойти до порядка. Зато работает везде и без всякой поддержки со стороны железа.

Виртуализация с KVM - другая история. Здесь QEMU опирается на аппаратные расширения процессора (Intel VT-x или AMD-V) и модуль ядра KVM, который живёт в Linux с 2007 года. Гостевая система исполняется прямо на физическом процессоре, а QEMU остаётся менеджером устройств. Для процессорных задач потери минимальны - единицы процентов от нативной скорости. На вводе-выводе разрыв заметнее, и там всё решают драйверы и настройка. Ограничение одно, зато жёсткое: архитектура гостя должна совпадать с архитектурой хоста. ARM на x86 через KVM не запустится никогда.

Понять, в каком режиме вы сейчас, проще всего по наличию /dev/kvm на хосте и ключу -enable-kvm в команде запуска. Если файла нет, а ключ вы не ставили - значит, всё крутится на TCG, и удивляться медленной виртуалке не нужно.

Есть и третий режим - user-mode. QEMU запускает не целую ОС, а отдельное приложение чужой архитектуры. Удобно для кросс-компиляции: собрали ARM-бинарник на x86-машине и тут же прогнали его, не поднимая виртуалку целиком.

QEMU или KVM - в чём разница

Вопрос звучит чаще всех остальных, и путаница в нём заложена самой терминологией.

KVM - это модуль ядра Linux. Он умеет одно: пускать гостевой код на физический процессор через аппаратные расширения и перехватывать привилегированные операции. Ни диска, ни сетевой карты, ни BIOS он гостю не даёт - у него просто нет для этого кода.

QEMU - это программа в пространстве пользователя, которая как раз всё перечисленное и рисует: чипсет, диски, сеть, видео, USB. Она может обойтись без KVM (тогда и процессор эмулирует сама, через TCG), а вот KVM без чего-то вроде QEMU бесполезен - гостю не на чем загрузиться.

Поэтому «QEMU против KVM» - вопрос некорректный. Это два слоя одного стека, и в 99% случаев вы используете их вместе. Когда говорят «гипервизор KVM», обычно имеют в виду именно связку. Подробнее про настройку этой связки - в отдельном разборе: настройка KVM на Linux.

Зачем это нужно в серверной инфраструктуре

Теперь от теории к применению. Где QEMU реально помогает?

CI/CD-пайплайны - классика. У вас embedded-проект на ARM, а билд-серверы на x86. QEMU позволяет прогнать юнит-тесты на эмулированной архитектуре прямо в GitLab CI или Jenkins. Медленнее, чем на реальном железе, зато не нужно держать зоопарк физических плат и следить, чтобы они были живы.

Разработка и тестирование драйверов и низкоуровневых компонентов. Сломать виртуалку не страшно: сделали снимок, поэкспериментировали, откатились. С production-сервером так не выйдет.

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

Миграция физических серверов в виртуальную среду (P2V). QEMU умеет live-миграцию - переносит работающую виртуалку между хостами без остановки сервисов. Для нагруженных систем это разница между «обновили железо в выходные» и «легли на четыре часа».

Тестирование обновлений ОС перед раскаткой в прод. Клонируете боевое окружение, накатываете патчи, смотрите, что отвалилось. Хорошо - катите на реальные серверы. Плохо - удаляете виртуалку.

Как это работает на практике

Обычно QEMU ставят вместе с libvirt - надстройкой, которая берёт на себя управление виртуалками. Вместо длинной командной строки вы описываете машину в XML и запускаете её через virsh или графический virt-manager.

Для продакшена чаще берут Proxmox VE - готовую платформу на базе QEMU и KVM, где кластеризация, веб-интерфейс и бэкапы уже собраны и настроены. Загрузили ISO, прокликали мастер, получили машину.

Установка и первый запуск

На Debian и Ubuntu базовый набор ставится одной командой:

На RHEL-подобных (Rocky, Alma, РЕД ОС) есть готовая группа пакетов:

Дальше стоит проверить, доступно ли аппаратное ускорение - иначе всё молча уедет на медленный TCG:

В выводе lscpu должна быть строка про VT-x или AMD-V, а /dev/kvm должен существовать. Флаги в процессоре есть, а устройства нет - почти всегда виртуализация выключена в прошивке материнской платы; как её найти и включить, разобрано отдельно: включить виртуализацию в BIOS.

Чтобы работать с виртуалками без sudo, добавьте себя в группы и перелогиньтесь - без выхода из сессии членство не подхватится:

Диск создаётся отдельной командой. Формат QCOW2 занимает место по мере заполнения и умеет снимки:

Каталог здесь домашний намеренно. Штатный /var/lib/libvirt/images принадлежит root, и попытка создать там образ от обычного пользователя упрётся в права - для ручных запусков проще держать образы у себя, а в /var/lib/libvirt/images складывать то, чем управляет libvirt.

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

А вот тот самый случай, ради которого QEMU обычно и вспоминают, - ARM-машина на x86-хосте. Здесь -enable-kvm уже не поставить, работает TCG, и нужна прошивка UEFI из отдельного пакета qemu-efi-aarch64:

Загрузится небыстро. Но загрузится - и без единой платы на столе.

Про диски стоит добавить ещё одно. Снимок QCOW2 - вещь удобная, но не бесплатная: пока он существует, все записи идут в цепочку файлов, и чем длиннее цепочка, тем медленнее диск. Снимок перед обновлением - хорошая практика. Снимок, забытый на полгода, - способ незаметно уронить производительность базы.

Для ввода-вывода используются драйверы VirtIO. Это паравиртуализированные устройства: они не притворяются конкретной сетевой картой Intel или Realtek, а честно сообщают гостю, что виртуальные, и общаются с ним напрямую, без прослойки эмуляции. Сеть и диск от этого ускоряются в разы. Windows-гостям драйверы VirtIO нужно подсовывать вручную при установке - в дистрибутиве их нет, и без них система просто не увидит диск.

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

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

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

PCIe passthrough (VFIO) - способ выжать максимум из конкретного устройства. Вы отдаёте виртуалке целиком видеокарту, RAID-контроллер или ускоритель, и гость работает с железом так, будто виртуализации нет. Полезно для GPU-вычислений. Цена - устройство больше никому на хосте не доступно, и живая миграция такой машины отменяется.

С числом vCPU есть две ловушки, и их постоянно путают между собой.

Первая - переподписка, когда суммарно всем машинам роздано больше vCPU, чем на хосте физических ядер. Сама по себе она нормальна и на том и стоит вся виртуализация: одновременно все машины работу процессору не создают. Вопрос в коэффициенте. Red Hat в документации по KVM называет безопасным ориентиром до 5 vCPU на физическое ядро при нагрузке ниже потолка и не советует переваливать за 10 суммарно. Практика скромнее: для смешанной офисной нагрузки спокойно живут при 3-4 к одному, для баз данных и 1С считают ближе к 1-2, а для тестовых стендов не считают вовсе.

Вторая ловушка обратная: одна машина с огромным числом vCPU. На 128-ядерном сервере виртуалка со ста vCPU почти наверняка будет работать хуже, чем с шестнадцатью. Планировщику приходится собирать столько свободных ядер одновременно, ядра расползаются по разным сокетам и узлам NUMA, память оказывается «чужой». Правило простое: давайте машине ровно столько vCPU, сколько она реально способна занять.

Безопасность и изоляция

Виртуализация - это и про удобство, и про безопасность. Каждая машина отделена от соседей: непроверенный код внутри одной не дотянется до других.

Но есть VM escape - класс уязвимостей, когда из виртуалки удаётся выбраться на хост. В QEMU такие находят регулярно: в одном только релизе 11.1 закрыли больше десятка уязвимостей в virtio, 9pfs и подсистеме NVMe. Отсюда практический вывод: гипервизор - не то ПО, которое можно поставить и забыть на три года. Обновления QEMU и ядра для хоста виртуализации важнее, чем для большинства других серверов, потому что цена одной дырки здесь - весь парк машин на хосте разом.

AMD добавила SEV-SNP - шифрование памяти гостевой системы, при котором даже администратор хоста не прочитает данные внутри машины. Для облачных провайдеров и всех, у кого высокие требования к конфиденциальности, вещь полезная, но требует поддержки со стороны процессора и заметной возни с настройкой.

В режиме KVM роль гипервизора минимальна: основная логика в ядре Linux. Это одновременно плюс и минус. Меньше кода - меньше поверхность атаки. Но уязвимость в KVM затрагивает сразу всё. Поэтому на хостах виртуализации накидывают дополнительные слои: SELinux или AppArmor, сетевая сегментация, отдельная сеть управления.

Интеграция с инфраструктурой

QEMU редко живёт сам по себе. Обычно поверх него стоит libvirt, и он же управляет Xen, LXC и VMware. Единый API означает, что скрипт автоматизации пишется один раз и переезжает между гипервизорами почти без правок.

Proxmox VE добавляет сверху веб-интерфейс, кластеризацию и бэкапы. Несколько серверов он объединяет в кластер, следит за нагрузкой и перезапускает машины при сбое узла. Для малого и среднего бизнеса это обычно проще и дешевле, чем VMware vSphere.

С облаками ситуация обратная расхожему мнению. Крупные провайдеры от QEMU как раз ушли. Google убрал его из Compute Engine ещё в 2017-м, заменив собственным монитором виртуальных машин - именно из-за широты QEMU: полтора десятка процессорных архитектур и сотни эмулируемых устройств означают большой объём кода и длинный список уязвимостей в анамнезе. AWS в системе Nitro пошла тем же путём: там урезанный KVM без QEMU, а устройства вынесены на отдельные аппаратные карты. Так что «внутри EC2 крутится QEMU» - устаревшее представление. Зато у себя в стойке вы получаете ровно ту гибкость, ради которой облачные гиганты и не смогли обойтись своими силами.

Для автоматизации есть провайдеры Ansible и Terraform. Инфраструктура описывается кодом, среда для тестов поднимается за минуты, сломанное проще пересоздать, чем чинить.

QEMU в российских платформах виртуализации

Для российской компании в 2026 году это, пожалуй, самая практическая часть темы. После ухода VMware выбор свёлся к отечественным платформам из реестра - и почти все они стоят на том же QEMU/KVM.

zVirt от Orion Soft - KVM плюс система управления, унаследованная от oVirt. В версии 5.0 появились собственная гипервизорная ОС zVirt Node 2.0 и живая миграция машин между ЦОД без общего хранилища. Лицензия - на физический сервер с двумя сокетами. Отдельная редакция zVirt Max сертифицирована ФСТЭК по 4 уровню доверия и допускается в КИИ, ГИС и ИСПДн.

ROSA Virtualization - та же связка oVirt и KVM от НТЦ ИТ РОСА, со ставкой на единого вендора: ОС, гипервизор и VDI из одних рук. В версии 4.0 (конец 2025-го) добавили ГОСТ-алгоритмы и встроенный Disaster Recovery, что среди российских платформ пока редкость.

«Альт Виртуализация» от «Базальт СПО» устроена иначе - это Proxmox VE, пересобранный под ОС «Альт». Вендор не переписывает функциональность, а делает стабильные сборки и поддержку. Для закупок важен нюанс: сертификат ФСТЭК тут выдан на операционную систему «Альт СП» с правом виртуализации, а у zVirt Max - на само средство виртуализации. Формулировки разные, и проверяющий смотрит именно на них.

Что это даёт админу практически: навыки переносимы. Понимание того, как QEMU раздаёт устройства, что делают VirtIO-драйверы и почему живая миграция требует одинаковых моделей процессора, работает одинаково в Proxmox, zVirt и ROSA. Меняется интерфейс управления и служба поддержки, а машинерия под ним одна. Подробное сравнение платформ в гиперконвергентных сценариях - в обзоре zVirt, ROSA и «Альт».

Сравнение с другими решениями

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

VirtualBox остаётся десктопной историей: на серверах его почти не встретишь. Hyper-V силён там, где Windows-инфраструктура уже построена и лицензии куплены, но с Linux-гостями KVM ведёт себя предсказуемее.

Контейнеры решают соседнюю задачу. Они легче и плотнее, но делят ядро с хостом, поэтому чужую ОС или эксперимент с ядром в них не унесёшь. Разница между подходами разобрана в сравнении Docker и LXC. На реальном сервере обычно работает и то и другое: контейнеры для сервисов, виртуалки для всего остального.

Экономика для руководителей

Главная статья экономии - консолидация. Вместо десяти отдельных серверов, каждый из которых загружен на 15%, вы берёте два-три мощных и распределяете нагрузку по виртуалкам. Меньше железа - меньше счёт за электричество и охлаждение, меньше юнитов в стойке, короче список того, что может сломаться.

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

Третья, менее очевидная, - скорость. Разработчики проверяют изменения в изолированных средах и не боятся сломать общий стенд, тестировщики гоняют регрессию параллельно на нескольких машинах, админы репетируют обновления до того, как трогать боевые серверы. Меньше согласований и ожидания - быстрее выходят изменения.

Ограничение тоже стоит назвать. Консолидация переносит риск: раньше отказ железа означал потерю одного сервиса, теперь - всех машин на этом хосте. Поэтому под виртуализацию берут технику с запасом и резервированием: два блока питания, ECC-память, RAID и диски с ресурсом под постоянную запись. Экономия на хосте виртуализации - худшее место для экономии из всех возможных.

Короткие ответы на частые вопросы

Зачем нужен QEMU, если есть KVM?
KVM без него не работает: модуль ядра умеет пускать код на процессор, но не даёт гостю ни диска, ни сети, ни прошивки. Всё это рисует QEMU.

Можно ли на x86-сервере запустить виртуалку с ARM?
Можно, но только через эмуляцию TCG - qemu-system-aarch64 без ключа -enable-kvm. Аппаратное ускорение при разных архитектурах недоступно в принципе.

Насколько сильно эмуляция бьёт по производительности?
Разброс большой. На целочисленной логике - в несколько раз, на плавающей точке и векторных инструкциях может дойти до порядка. Для сборки и тестов приемлемо, для боевой нагрузки - нет.

Какой процессор нужен, чтобы что-то эмулировать?
Для режима TCG - любой: аппаратная поддержка ему не требуется, разница будет только в скорости. Для быстрой виртуализации через KVM нужны Intel VT-x или AMD-V, а на серверных процессорах последних поколений они есть всегда - вопрос лишь в том, включены ли в прошивке.

Подходит ли QEMU для продакшена или это только для тестов?
Подходит, и давно: связка QEMU + KVM лежит в основе Proxmox VE, zVirt, ROSA Virtualization и «Альт Виртуализации». В чистом виде, командной строкой, в продакшене его действительно почти не запускают - берут платформу с управлением поверх.

Сколько стоит?
Сам QEMU бесплатен, лицензия GPL. Платить приходится за платформу управления и поддержку, если они нужны, - и за железо, на котором всё это будет крутиться.