Что такое qemu kvm
Обновлено: 02.07.2024
KVM, виртуальная машина на основе ядра, представляет собой гипервизор, встроенный в ядро Linux. Он похож на Xen по назначению, но его гораздо проще запустить. В отличие от родного QEMU, использующего эмуляцию, KVM – это особый режим работы QEMU, в котором для виртуализации через модуль ядра используются расширения ЦП (HVM).
Различия между KVM и Xen, VMware или QEMU можно найти в FAQ по KVM.
В этой статье не рассматриваются функции, общие для нескольких эмуляторов, использующих KVM в качестве серверной части. Вы должны увидеть соответствующие статьи для получения такой информации.
Содержание
Проверка поддержки KVM
Поддержка оборудования
KVM требует, чтобы процессор хоста виртуальной машины поддерживал виртуализацию (с именем VT-x для процессоров Intel и AMD-V для процессоров AMD). Проверить, поддерживает ли ваш процессор аппаратную виртуализацию, можно с помощью следующей команды:
Если после выполнения какой-либо команды ничего не отображается, ваш процессор не поддерживает аппаратную виртуализацию, и вы не сможете использовать KVM.
Примечание. Возможно, вам потребуется включить поддержку виртуализации в BIOS. Все процессоры x86_64, произведенные AMD и Intel за последние 10 лет, поддерживают виртуализацию. Если похоже, что ваш процессор не поддерживает виртуализацию, почти наверняка она отключена в BIOS.
Поддержка ядра
Ядра Arch Linux предоставляют необходимые модули ядра для поддержки KVM.
- Можно проверить, доступны ли в ядре необходимые модули, kvm и либо kvm_amd, либо kvm_intel , с помощью следующей команды:
Модуль доступен, только если для него задано значение y или m .
- Затем убедитесь, что модули ядра загружаются автоматически, с помощью команды:
Совет. Если modprobing kvm_intel или kvm_amd завершается неудачно, но modprobing kvm завершается успешно, а lscpu утверждает, что поддерживается аппаратное ускорение, проверьте настройки BIOS. Некоторые поставщики, особенно поставщики ноутбуков, по умолчанию отключают эти расширения процессора. Чтобы определить, нет ли аппаратной поддержки или отключены ли расширения в BIOS, об этом сообщит вывод dmesg после неудачной попытки modprobe.
Паравиртуализация с Virtio
Паравиртуализация предоставляет гостям быстрое и эффективное средство связи для использования устройств на хост-компьютере. KVM предоставляет паравиртуализированные устройства для виртуальных машин, используя API Virtio в качестве слоя между гипервизором и гостем.
Все устройства Virtio состоят из двух частей: хост-устройство и гостевой драйвер.
Поддержка ядра
Используйте следующую команду, чтобы проверить, доступны ли модули VIRTIO в ядре внутри виртуальной машины:
Затем проверьте, загружаются ли модули ядра автоматически, с помощью команды:
Если приведенные выше команды ничего не возвращают, вам необходимо загрузить модули ядра вручную.
Список паравиртуализированных устройств
- сетевое устройство (virtio-net)
- заблокировать устройство (virtio-blk)
- контроллер (virtio-scsi)
- последовательное устройство (virtio-serial)
- воздушное устройство (virtio-balloon)
Как использовать KVM
См. основную статью: QEMU.
Советы и рекомендации
Вложенная виртуализация
Вложенная виртуализация позволяет запускать существующие виртуальные машины на сторонних гипервизорах и в других облаках без каких-либо изменений исходных виртуальных машин или их сети.
На хосте включите вложенную функцию для kvm_intel:
Убедитесь, что функция активирована:
Включите режим «сквозной передачи хоста», чтобы перенаправить все функции ЦП в гостевую систему:
- При использовании QEMU запустите гостевую виртуальную машину с помощью следующей команды: qemu-system-x86_64 -enable-kvm -cpu host .
- При использовании virt-manager измените модель ЦП на host-passthrough .
- При использовании virsh используйте virsh edit vm-name и измените строку CPU на
Загрузите виртуальную машину и проверьте наличие флага vmx:
Включение огромных страниц
Эта статья или раздел являются кандидатами на слияние с QEMU.
Примечания: qemu-kvm больше не существует, так как все его функции были объединены в qemu . После того, как вышеуказанная проблема будет устранена, я предлагаю объединить этот раздел в QEMU. (Обсудить в разговоре:KVM)
Вы также можете включить огромные страницы, чтобы повысить производительность вашей виртуальной машины. С последней версией Arch Linux и работающим KVM у вас, вероятно, уже есть все, что вам нужно. Проверьте, есть ли у вас каталог /dev/hugepages. Если нет, создайте его. Теперь нам нужны правильные разрешения для использования этого каталога. Разрешение по умолчанию — uid root и gid с 0755, но мы хотим, чтобы любой в группе kvm имел доступ к hugepages.
Добавить в /etc/fstab:
Конечно, gid должен совпадать с gid группы kvm или указывать имя группы непосредственно с помощью gid=kvm .Режим 1770 позволяет любому члену группы создавать файлы, но не отсоединять и не переименовывать файлы друг друга. Убедитесь, что /dev/hugepages правильно смонтированы:
Обычно это должно быть 2048 КБ ≙ 2 МБ. Допустим, вы хотите запустить виртуальную машину с 1024 МБ. 1024 / 2 = 512. Добавьте еще несколько, чтобы мы могли округлить это число до 550. Теперь сообщите своей машине, сколько огромных страниц вам нужно:
Если у вас достаточно свободной памяти, вы должны увидеть:
Если число меньше, закройте некоторые приложения или запустите виртуальную машину с меньшим объемом памяти (количество_страниц x 2):
Обратите внимание на параметр -mem-path. Это позволит использовать огромные страницы.
Теперь вы можете проверить, сколько страниц используется во время работы вашей виртуальной машины:
Я некоторое время читал о KVM и Qemu. На данный момент у меня есть четкое представление о том, что они делают.
KVM поддерживает аппаратную виртуализацию, чтобы обеспечить почти нативную производительность гостевых операционных систем. С другой стороны, QEmu эмулирует целевую операционную систему.
Что меня смущает, так это то, на каком уровне они координируются. Нравится
- Кто управляет совместным использованием ОЗУ и/или памяти?
- Кто планирует операции ввода-вывода?
Есть также книга QEMU с официальным названием QEMU, Kernel-based Virtual Machine (KVM), Xen & libvirt. но полностью на немецком. Тем не менее, есть ссылка на английскую версию, переведенную Google. (Пожалуйста, пусть это вас не обескураживает: перевод следует немецкому тексту с высокой точностью, что также является показателем огромных усилий авторов, чтобы объяснить такую сложную тему простыми терминами и предложениями.)
3 ответа 3
Кэму:
QEmu — это полноценное автономное программное обеспечение. Вы используете его для эмуляции машин, он очень гибкий и портативный. В основном он работает с помощью специального «перекомпилятора», который преобразует двоичный код, написанный для данного процессора, в другой (например, для запуска кода MIPS на PPC Mac или ARM на ПК с архитектурой x86).
Чтобы эмулировать больше, чем просто процессор, Qemu включает длинный список эмуляторов периферийных устройств: дисковые, сетевые, VGA, PCI, USB, последовательные/параллельные порты и т. д.
KQэму:
В конкретном случае, когда и исходная, и целевая архитектура имеют одну и ту же архитектуру (например, общий случай x86 на x86), все равно необходимо проанализировать код, чтобы удалить все «привилегированные инструкции» и заменить их переключателями контекста. Чтобы сделать это максимально эффективным в x86 Linux, существует модуль ядра под названием KQemu, который справляется с этим.
Являясь модулем ядра, KQemu может выполнять большую часть кода без изменений, заменяя только инструкции нижнего уровня только для Ring0. В этом случае пользовательское пространство Qemu по-прежнему выделяет всю оперативную память для эмулируемой машины и загружает код. Разница в том, что вместо перекомпиляции кода он вызывает KQemu для его сканирования/исправления/выполнения. Вся эмуляция периферийного оборудования выполняется в Qemu.
Это намного быстрее, чем простой Qemu, потому что большая часть кода остается неизменной, но по-прежнему необходимо преобразовывать код Ring0 (большая часть кода находится в ядре виртуальной машины), поэтому производительность по-прежнему страдает.
КВМ:
KVM — это несколько вещей: во-первых, это модуль ядра Linux, теперь включенный в основную ветку, который переключает процессор в новое «гостевое» состояние. Состояние гостя имеет свой собственный набор состояний кольца, но инструкции привилегированного кольца 0 возвращаются к коду гипервизора. Поскольку это новый режим выполнения процессора, код не нужно каким-либо образом изменять.
Помимо переключения состояния процессора, модуль ядра также обрабатывает несколько низкоуровневых частей эмуляции, таких как регистры MMU (используемые для управления виртуальной машиной) и некоторые части эмулируемого оборудования PCI.
Во-вторых, KVM является ответвлением исполняемого файла Qemu. Обе команды активно работают над тем, чтобы свести различия к минимуму, и есть успехи в их уменьшении. В конце концов, цель состоит в том, чтобы Qemu работал где угодно, и если доступен модуль ядра KVM, его можно было бы использовать автоматически. Но в обозримом будущем команда Qemu сосредоточится на аппаратной эмуляции и переносимости, в то время как разработчики KVM сосредоточатся на модуле ядра (иногда перемещая туда небольшие части эмуляции, если это улучшит производительность) и взаимодействии с остальным кодом пользовательского пространства.
Исполняемый файл kvm-qemu работает как обычный Qemu: выделяет оперативную память, загружает код и вместо его перекомпиляции или вызова KQemu запускает поток (это важно). Поток вызывает модуль ядра KVM для переключения в гостевой режим и приступает к выполнению кода виртуальной машины. По привилегированной инструкции он переключается обратно на модуль ядра KVM, который при необходимости сигнализирует потоку Qemu обработать большую часть аппаратной эмуляции.
Одним из преимуществ этой архитектуры является то, что гостевой код эмулируется в потоке posix, которым можно управлять с помощью обычных инструментов Linux.Если вам нужна виртуальная машина с 2 или 4 ядрами, kvm-qemu создает 2 или 4 потока, каждый из которых вызывает модуль ядра KVM для начала выполнения. Параллелизм — если у вас достаточно реальных ядер — или планирование — если нет — управляется обычным планировщиком Linux, благодаря чему код остается небольшим, а неожиданности ограничиваются.
Гипервизор KVM является центральной частью продуктов Red Hat, таких как Red Hat Virtualization, Red Hat OpenStack Platform и надстройка Container-Native Virtualization для Red Hat OpenShift Container Platform. Роль KVM заключается в включении и управлении возможностями аппаратной виртуализации процессора; это позволяет виртуальным машинам работать со скоростью, близкой к исходной, для самых разных рабочих нагрузок.
KVM сам по себе является «просто» драйвером устройства Linux и только одной частью нашего стека виртуализации. Компоненты пользовательского пространства, такие как QEMU и libvirt, и другие подсистемы ядра, такие как SELinux, играют важную роль в создании полнофункционального и безопасного стека. В этом посте мы рассмотрим сторону пользовательского пространства стека виртуализации KVM, какие существуют альтернативы QEMU и libvirt и как наша работа над QEMU и libvirt может сделать их подходящими для еще более широкого диапазона вариантов использования.
QEMU и libvirt
QEMU и libvirt образуют серверную часть стека виртуализации пользовательского пространства Red Hat: они используются нашими продуктами на основе KVM и несколькими приложениями, включенными в Red Hat Enterprise Linux, такими как virt-manager, libguestfs и GNOME Boxes.
QEMU и libvirt выполняют дополнительные задачи. QEMU — это монитор виртуальной машины (VMM): он обеспечивает аппаратную эмуляцию и низкоуровневый интерфейс для виртуальной машины. Процесс QEMU сам по себе является виртуальной машиной: вы можете завершить его, отправив сигнал процессу, проверить потребление ресурсов процессора с помощью команды top и т. д.
Однако способ, которым мы запускаем QEMU, заключается в том, что многоуровневые продукты просят libvirt выполнять операции с виртуальными машинами, такие как запуск, остановка или перенос их на другой хост. На самом деле мы продвигаем эту модель на шаг вперед, поскольку все программное обеспечение, использующее KVM, поставляемое Red Hat, должно делать это через libvirt. Причина в том, что libvirt — это больше, чем просто интерфейс управления: разделение QEMU/libvirt также чрезвычайно важно для безопасности.
Поскольку процесс QEMU обрабатывает ввод и команды от гостя, он подвергается потенциально вредоносной активности. Следовательно, он должен работать в ограниченной среде, где у него есть доступ только к ресурсам, необходимым для запуска виртуальной машины. Это принцип наименьших привилегий, которому должны следовать QEMU и libvirt [1].
Libvirt, с другой стороны, невидим для гостей, поэтому это лучшее место для ограничения процессов QEMU; не имеет значения, если для настройки среды с ограниченным доступом требуются высокие привилегии. Libvirt сочетает в себе множество технологий для ограничения QEMU, начиная от владения файловой системой и разрешений и заканчивая cgroups и мультикатегориальной безопасностью SELinux. Вместе эти технологии направлены на то, чтобы QEMU не мог получить доступ к ресурсам с других виртуальных машин.
Рисунок 1. libvirt и QEMU построены на различных подсистемах Linux
Такое использование libvirt является одной из причин, по которой Red Hat иногда присваивает уязвимостям более низкие оценки CVSS, чем исходные проекты или даже сторонние организации, такие как Национальная база данных уязвимостей. Возьмем, к примеру, CVE-2015-3456, переполнение буфера в QEMU, которое может обеспечить выполнение кода от гостя к хосту в процессе QEMU. Национальная база данных уязвимостей присваивает ему 7,7 балла (высокий), в то время как присвоенный Red Hat балл составляет 6,5. Это связано с тем, что для выхода из ограниченной среды QEMU требуются дополнительные эксплойты для повышения привилегий. Таким образом, ошибка считается менее пригодной для использования в стеке QEMU+libvirt.
Внешний мир
Несмотря на то, что QEMU и libvirt являются наиболее часто используемыми пользовательскими пространствами KVM, они ни в коем случае не являются единственными проектами с открытым исходным кодом в этой области.
Большинство из множества существующих альтернатив предназначены для определенных ниш. Например, одним из первых альтернативных вариантов пользовательского пространства KVM является kvmtool. Запущенный в 2011 году и называвшийся в то время lkvm, он был ориентирован на разработчиков ядра Linux, предоставляя им более простой способ использования виртуальных машин для работы в Linux. В наши дни он в основном используется для запуска KVM на новых архитектурах.
Еще один важный монитор виртуальных машин на базе KVM — crosvm. Crosvm был разработан Google для запуска приложений Linux внутри ChromeOS. Проект стартовал в 2017 году и является частью более крупного стека поддержки под названием Crostini. В этот стек также входит привилегированный демон установки под названием Concierge, на который возложены те же обязанности, что и на libvirt.
Рис. 2. crosvm прозрачно интегрирует настольные приложения Linux в ChromeOS. Снимок экрана: Зак Рейзнер, лицензия Creative Commons Attribution 2.0 Generic License.
Один интересный аспект crosvm заключается в том, что он написан с использованием языка программирования Rust. Вместо этого QEMU и kvmtool написаны на почтенном языке C. Поскольку монитор виртуальной машины потенциально подвержен злонамеренной гостевой активности, характеристики безопасности Rust, безусловно, желательны.
По этой причине Amazon также обратилась к Rust за работой по запуску функций AWS Lambda внутри виртуальных машин. Монитор виртуальной машины, который Amazon использует для Lambda, называется Firecracker, имеет открытый исходный код и был создан на основе crosvm [2] . Firecracker имеет очень минимальный набор функций; на самом деле вам даже понадобится специально скомпилированное ядро для вашей виртуальной машины вместо того, чтобы использовать ядро из вашего любимого дистрибутива. Стек управления Amazon для Firecracker не является открытым исходным кодом, за исключением простого инструмента для песочницы, называемого джейлером. Этот инструмент позаботится о настройке пространств имен и seccomp в соответствии с процессом Firecracker.
Инженеры Amazon также начали проект под названием rust-vmm, совместную разработку общих библиотек для проектов виртуализации, написанных на Rust. Эти библиотеки, или «ящики» на языке Rust, могут использоваться мониторами виртуальных машин, серверами vhost-user [3] или другими специализированными вариантами использования KVM. Intel создала один такой VMM, названный cloud-hypervisor, который также можно считать эталонной реализацией rust-vmm.
Другим пользователем rust-vmm может быть собственный проект Red Hat Enarx. Запущенный в мае 2019 года на саммите Red Hat, Enarx обеспечивает абстракцию платформы для доверенных сред выполнения (TEE). Enarx, который тоже написан на Rust, напрямую не является проектом виртуализации. Однако он использует KVM на платформах, где расширения аппаратной виртуализации предоставляют TEE. Ярким примером является функция безопасной зашифрованной виртуализации процессоров AMD EPYC.
Я закончу этот обзор двумя проектами, которые стирают границы между контейнерами и виртуальными машинами: gVisor и контейнеры Kata. Оба этих проекта предоставляют среду выполнения OCI, которая использует KVM для улучшения изоляции контейнеров от хоста. Обратите внимание, что это отличается от KubeVirt, который поддерживает CNV OpenShift и позволяет вам управлять традиционными виртуальными машинами с помощью API контейнера Kubernetes.
Подобно Enarx, gVisor (также проект Google) не является традиционным монитором виртуальной машины. Вместо реализации аппаратного интерфейса на основе эмулируемых устройств gVisor настраивает гостевую систему так, чтобы она перехватывала хост при системных вызовах. Затем он проверяет параметры и передает их хосту. Дополнительный уровень улучшает изоляцию по сравнению с традиционными контейнерами, хотя, конечно, за производительность приходится платить.
Контейнеры Kata, с другой стороны, настраивают виртуальную машину так, чтобы она «выглядела как контейнер», например, разделяя части файловой системы хоста с виртуальной машиной, и запускает ее с помощью QEMU или Firecracker. Ограниченный набор функций Firecracker слишком ограничен для контейнеров Kata, поэтому QEMU является рекомендуемым монитором виртуальных машин для большинства применений.
Kata Containers вызывает монитор виртуальной машины напрямую — он не использует libvirt, поэтому я включил его в этот список альтернатив QEMU/libvirt. Однако управление QEMU в Kata Containers не такое зрелое, как в libvirt; он запускает QEMU от имени пользователя root и не поддерживает SELinux. Red Hat работает с разработчиками Kata над решением этих проблем и над упрощением использования Libvirt для среды выполнения контейнеров Kata.
Будущее QEMU и libvirt
Все эти проекты, безусловно, могут многому научить нас, разработчиков QEMU и libvirt. На самом деле, мы уже усвоили некоторые из этих уроков на собственном горьком опыте. Kata Containers и предшественник Clear Containers дважды разветвляли QEMU, сначала в 2016 году, а затем в 2018 году, хотя последний выпуск Kata Containers, выпущенный в июле 2019 года, обновил QEMU до исходной версии 4.0.
Главный урок, который мы усвоили, заключается в том, что восприятие имеет значение. Как только достаточное количество людей поверит, что QEMU слишком большой и небезопасный, написания отличного программного обеспечения будет недостаточно, чтобы убедить их в обратном. Вместо этого вы всегда должны рассказывать людям о своей работе и объяснять, чем и почему она прекрасна! Kata Containers смогла отказаться от своих форков QEMU, потому что мы выслушали людей в этом сообществе, предоставили им технические рекомендации и предложили помощь в объединении кода и идей из их форков в исходный QEMU [4] .
Доступность альтернативных мониторов виртуальных машин также позволяет нам черпать вдохновение из идей других людей и расширять границы QEMU.
Например, мы исследуем виртуальные машины, совместимые с Firecracker, в QEMU. В наших экспериментах такая виртуальная машина может загрузить ядро Linux примерно за 100 миллисекунд, включая время, необходимое для загрузки и запуска QEMU. Хотя это виртуальное оборудование будет разделять многие ограничения Firecracker, его можно будет запускать в безопасной среде, предоставляемой libvirt, и многие расширенные функции QEMU останутся доступными. В частности, использование функции моментального снимка виртуальной машины QEMU может еще больше ускорить загрузку.
Рисунок 3. Загрузка совместимой с Firecracker «микро-ВМ» с помощью QEMU
Проект libvirt также проходит процесс самоанализа, пересматривая исторические проектные решения, чтобы переоценить их актуальность для современных сценариев виртуализации. Монолитная архитектура демона libvirtd постепенно заменяется небольшими демонами для каждого драйвера и RPC. Доказательство концепции «встроенного» режима драйвера может даже позволить управлению QEMU работать без демона.
В настоящее время предпринимаются усилия по консолидации использования языков программирования в libvirt. Это включает в себя замену использования сценариев оболочки и переписывание сценариев Perl для стандартизации на Python, а также замену системы сборки на основе Autotools на Meson. Современные языки системного программирования, такие как Rust и Go, также могут заменить C для некоторых модулей libvirt. Это позволит разработчикам воспользоваться их многочисленными преимуществами по сравнению с C и потенциально открыть новые способы использования функций libvirt из таких приложений, как KubeVirt или Kata Containers.
Выводы
KVM предоставляет инфраструктуру ядра для широкого спектра мониторов и приложений виртуальных машин, от классической корпоративной виртуализации до инновационных решений для песочницы, таких как gVisor и Enarx.
Red Hat выбрала QEMU и libvirt как мощную комбинацию, которая взаимодействует с KVM, чтобы обеспечить безопасный, эффективный и полнофункциональный стек виртуализации. Фактически, по сей день это остается наиболее многофункциональным способом использования виртуализации KVM. Однако наличие альтернатив способствует появлению новых идей и держит сообщество в напряжении. Знание того, что происходит, и изучение этих новых границ поучительно и даже необходимо для того, чтобы QEMU и libvirt оставались здоровыми проектами. Никогда не поздно научиться новым трюкам!
Примечания
[1] Для получения дополнительной информации об архитектуре безопасности QEMU см. презентацию Стефана Хайноци на KVM Forum 2018; доступны видео и слайды.
[2] И Amazon, и Google также используют KVM для своих общедоступных облачных сервисов, соответственно EC2 и GCE. Однако программное обеспечение GCE и EC2 не является открытым исходным кодом, и его не следует путать с crosvm и Firecracker.
[3] vhost-user — это стандартная архитектура для многопроцессорных устройств virtio. Клиент vhost-user является монитором виртуальной машины, а сервер обеспечивает реализацию устройства.
[4] Прямое слияние форка с вышестоящим QEMU иногда было невозможно из-за технических проблем или проблем с ремонтопригодностью. Однако, работая с разработчиками Kata, мы смогли выделить их требования (например, «улучшить использование оперативной памяти хоста и скорость загрузки за счет запуска несжатого образа Linux») и повторно реализовать их удовлетворительным или даже улучшенным образом.
Если бы вы спросили кого-нибудь, «какой гипервизор с открытым исходным кодом самый популярный», скорее всего, ответом будет KVM. Действительно, KVM (или виртуальная машина на основе ядра) сыграла ключевую роль в среде виртуализации на базе Linux с открытым исходным кодом. Однако действительно ли это гипервизор? Более того, может ли KVM сам по себе запускать виртуальные машины? Мы углубимся в такие вопросы в этом блоге. Мы также поймем взаимосвязь между KVM и QEMU (Quick EMUlator).
KVM и QEMU — проверка идентификатора процесса
Для запуска виртуальной машины можно использовать libvirt и соответствующий графический интерфейс диспетчера виртуальных машин. В графическом интерфейсе вы можете выбрать «Тип Virt» как KVM или QEMU. Я запустил виртуальную машину, один раз с QEMU в качестве типа Virt и один раз с KVM. В обоих случаях я выполнил grep идентификатор процесса, чтобы увидеть, есть ли разница. Примечание. Для своих экспериментов я использовал Ubuntu 13.10.
KVM и QEMU — VMM Select Virt Type
Когда я запустил виртуальную машину с KVM в качестве типа Virt, в деталях идентификатора процесса был показан интересный атрибут «accel=kvm», как показано ниже.
QEMU с использованием ускорителя KVM
Когда я запускал ту же виртуальную машину с QEMU, что и Virt Type, идентификатор процесса показывал «accel=tcg».
QEMU с использованием ускорителя TCG
Обратите внимание, что в обоих случаях для запуска виртуальной машины выполняется один и тот же двоичный файл, а именно qemu-system-x86_64. Основное отличие заключается в типе ускорения.
KVM и QEMU: аппаратное ускорение
Чтобы понять аппаратное ускорение, мы должны понять, как работает ЦП виртуальной машины. В реальном оборудовании операционная система (ОС) переводит программы в инструкции, которые выполняются физическим ЦП. В виртуальной машине происходит то же самое. Однако ключевое отличие заключается в том, что виртуальный ЦП фактически эмулируется (или виртуализируется) гипервизором. Следовательно, программное обеспечение гипервизора должно перевести инструкции, предназначенные для виртуального ЦП, и преобразовать их в инструкции для физического ЦП. Этот перевод сильно снижает производительность.
Чтобы свести к минимуму эти потери производительности, современные процессоры поддерживают расширения виртуализации. Intel поддерживает технологию VT-x, а ее эквивалент AMD — AMD-V. Используя эти технологии, кусок физического процессора можно напрямую сопоставить с виртуальным процессором. **Следовательно, инструкции, предназначенные для виртуального ЦП, могут выполняться непосредственно на физическом срезе ЦП. **
KVM – это модуль ядра Linux, который позволяет отображать физический ЦП на виртуальный ЦП. Это сопоставление обеспечивает аппаратное ускорение для виртуальной машины и повышает ее производительность. Более того, QEMU использует это ускорение, когда в качестве KVM выбран Virt Type.
Тогда что такое TCG? Если ЦП вашего сервера не поддерживает расширение виртуализации, то задача эмулятора (или гипервизора) заключается в выполнении инструкции виртуального ЦП с использованием трансляции. QEMU использует TCG или Tiny Code Generator для оптимального _преобразования и выполнения _инструкций виртуального ЦП на физическом ЦП.
KVM и QEMU — гипервизор типа 1 или типа 2
Веб-страницы KVM и QEMU ясно показывают, что KVM нужен QEMU для обеспечения полной функциональности гипервизора. Сам по себе KVM больше похож на поставщика инфраструктуры виртуализации.
< /p>
Взаимосвязь KVM и QEMU
QEMU сам по себе является гипервизором второго типа. Он перехватывает инструкции, предназначенные для виртуального ЦП, и использует операционную систему хоста для выполнения этих инструкций на физическом ЦП. Когда QEMU использует KVM для аппаратного ускорения, комбинация становится гипервизором типа 1. Эта разница хорошо видна из описания на сайте QEMU.
< /p>
Взаимосвязь KVM и QEMU
KVM и QEMU — зависимость x86
Поскольку KVM на самом деле является драйвером для физических возможностей ЦП, он очень тесно связан с архитектурой ЦП (архитектурой x86). Это означает, что преимущества аппаратного ускорения будут доступны только в том случае, если ЦП виртуальной машины использует ту же архитектуру (x86).
Если на виртуальной машине должен работать процессор Power PC, а на сервере гипервизора установлен процессор Intel, то KVM не будет работать. Вы должны использовать QEMU в качестве типа Virt и смириться с накладными расходами на производительность.
KVM и QEMU - заключение
Исходя из приведенного выше обсуждения, совершенно очевидно, что QEMU играет очень важную роль в решениях виртуализации с открытым исходным кодом на базе Linux. Для всех практических приложений QEMU требуется повышение производительности KVM. Однако ясно, что **KVM сам по себе не может обеспечить полное решение для виртуализации. Ему нужен QEMU.
Читайте также: