Производительность QEMU (все еще) отстает от VirtualBox и есть ли способ улучшить ее без аппаратной поддержки + модуля ядра kvm?

Я заметил несколько статей, в которых утверждалось, что QEMU работает медленнее, чем VirtualBox (без помощи аппаратного обеспечения), но некоторым уже несколько лет, и новейшая версия, похоже, появилась в прошлом году.

Правда ли, что QEMU медленнее, чем VirtualBox?
Если так, то почему?
Есть ли какие-то хитрости, чтобы закрыть разрыв в производительности?

Некоторые из моих хост-систем не поддерживают аппаратную виртуализацию, поэтому мне особенно интересны советы по производительности, которые работают без модуля ядра.

virtualbox virtualization qemu

— Catskul
источник

Ответы:

Если вы говорите о виртуализации x86 на хосте x86, имейте в виду, что kqemu (старый модуль ядра ускорения для qemu) устарел. Виртуальная машина ядра (KVM) - это «путь вперед», но он работает только на хостах Linux. Гость может быть любой ОС, какой вы пожелаете, если это архитектура x86.

Кросс-архитектура, QEMU по-прежнему очень медленно; только сегодня я пытался установить последнюю версию qemu с Debian MIPS64 в гостевой системе ... ее можно было использовать из терминала, но в Xorg это было ужасно медленно. Насколько мне известно, вы не можете использовать инструкции по ускорению процессора, такие как расширенные таблицы страниц или VT-x, когда вы собираетесь кросс-архитектуры. Это все эмулируется в программном обеспечении.

Таким образом, для виртуализации от x86 до x86 «сырая» qemu медленная, но KVM (которая использует qemu) быстрая. Довольно быстро. Настолько быстро, что это рекомендуемое Red Hat решение для виртуализации RHEL.

VirtualBox по-прежнему отбрасывает все, что может предложить qemu / kvm, с точки зрения производительности 2D / 3D-графики с аппаратным ускорением, поскольку kvm фокусируется на виртуализации серверов, а virtualbox - на виртуализации десктопов. Но я определенно рекомендую вам проверить kvm, если вы имеете дело с сервером.

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

— allquixotic
источник

ls $(which kvm)показывает символическую ссылку на qemu-system-x86_64. Я предполагаю, что это именно то, о чем вы говорили с KVM, используя QEMU?

— Catskul

Да, но KVM - это, как следует из названия, виртуальная машина на основе ядра , что означает, что кишки гипервизора находятся в модуле ядра 'kvm'. Вы можете думать о нем как о похожем на старый kqemu, если хотите, но с архитектурной точки зрения он сильно отличается. qemu - это больше интерфейс, чем настоящий гипервизор, когда kvm работает.

— allquixotic

О, я забыл добавить: причина того, почему qemu (и любая другая система виртуализации) так медленна без «модуля ядра» (как вы говорите, на самом деле вы имеете в виду «без аппаратного ускорения»), заключается в том, что определенные аппаратные операции Гость очень трудно эмулировать в программном обеспечении. Ну не сложно с точки зрения ненадежности или сложности; просто sloooooooooooooow. Вот почему Intel потратила большую часть десятилетия, давая нам аппаратно-ускоренные инструкции для самых медленных битов виртуализации на пути VT-x и EPT. Единственным исправлением является использование оборудования, которое поддерживает эти наборы инструкций.

— allquixotic

Есть ли что-то, что делает virtualbox быстрее даже без аппаратного ускорения?

— Catskul

Нет. Без аппаратного ускорения производительность должна быть примерно одинаковой. VirtualBox может иметь расширенные возможности оптимизации x86, которые позволяют ему работать немного быстрее в программном обеспечении, что было бы целесообразно, поскольку virtualbox в первую очередь поддерживает только x86, в то время как qemu имеет гораздо более широкое игровое поле (архитектуры не x86). Но это детали реализации / проектирования, которые в основном сводятся к локальности кэша, оптимизированным внутренним циклам, ручному кодированию на ассемблере, кэшированию дискового ввода-вывода на стороне хоста или другим хитростям. Не уверен, в какой степени vbox делает то, чего не делает qemu, но они не очень актуальны ...

— allquixotic

Предполагается, что хост с процессором с поддержкой виртуализации (Intel VT-x, AMD SVM), на котором запущено Qemu на ядре (Linux с KVM), работает достаточно быстро.

Мне неясны технические причины, по которым Qemu медленно работает с 2D (YouTube, электронная таблица, игры) и 3D-эмуляцией. Тем не менее, я могу предположить, что «видеодрайверы» просто недостаточно хороши - аппаратное графическое оборудование не используется оптимальным образом.

С другой стороны, недавняя разработка представила инфраструктуру SPICE для qemu. На самом деле это несколько лет и кажется достаточно зрелым. Преимущества работы с видео драйвером QXL огромны по моему опыту (2D-веб-разработка). Я не знаю, насколько хорошо он сравнивается с Virtualbox, но это определенно улучшение. Я думаю, что SPICE является обязательным для всех, кто работает под управлением Windows в Qemu.

Это исключительно мое мнение, и следует заметить, что я никогда даже не пытался запустить воспроизведение 3D или видео в гостевой системе.

— Ярослав Рахматуллин
источник

Если под «графически-ориентированной эмуляцией» вы ссылаетесь на 3D-ускорение, то это потому, что графические процессоры нельзя виртуализировать подобно процессорам. Программная эмуляция невероятно медленная, поэтому в настоящее время существует два решения: 1. Переход через API (т. Е. Вызовы DirectX в гостевой системе выполняются как вызовы DirectX на хосте) 2. Переход через VGA (реальная сделка: вся графическая карта становится доступной). к гостю). QEMU поддерживает # 2.

— Маркус

@Marcus Passthrough - это путь.

— Ярослав Рахматуллин