Система виртуализации QEMU
Обновлено 24 января 2020
KVM (Kernel-based Virtual Machine) — это программное решение, обеспечивающее виртуализацию в среде Linux, которая поддерживает аппаратную виртуализацию на базе Intel VT (Virtualization Technology) либо AMD SVM (Secure Virtual Machine).
QEMU — свободная программа с открытым исходным кодом для эмуляции аппаратного обеспечения различных платформ, которая может работать и без использования KVM, но использование аппаратной виртуализации значительно ускоряет работу гостевых систем, поэтому использование KVM в QEMU (enable-kvm) является предпочтительным вариантом.
Первоначально разработка велась в рамках проекта Linux KVM (Kernel-based Virtual Machine), в котором, помимо собственно KVM (поддержки технологий аппаратной виртуализации x86-совместимых процессоров на уровне ядра Linux), разрабатывались патчи для QEMU, позволяющие QEMU использовать функциональность KVM. Однако недавно разработчики QEMU в содружестве с разработчиками KVM приняли решение интегрировать поддержку KVM в основную ветку QEMU (mainline).
Используя KVM, вы может запустить несколько виртуальных машин с немодифицированными образами Linux и Windows. Каждая виртуальная машина имеет собственную приватную среду, в которой она работает: сетевую карту, диск, графический адаптер и т.д.
Поддержка KVM вошла в ядро Linux начиная с версии 2.6.20.
libvirt — это интерфейс и демон для управления виртуальными машинами различных технологий (qemu/kvm, xen, virtualbox), он позволяет удобно настраивать и манипулировать виртуальными машинами. Также к нему есть много разных сторонних приложений для управления, web-интерфейсов и т.д. Например, весьма полезным может быть графический интерфейс управления виртуальными машинами virt-manager .
Установка пакетов
По умолчанию QEMU поддерживает архитектуры i386 и x86_64. Отредактируйте флаги для поддержки необходимых гостевых машин. Пример добавления поддержки архитектуры arm :
Для установки QEMU и libvirt выполните:
emerge -a app-emulation/qemu app-emulation/libvirt
Источник
IP-KVM через QEMU
Устранение неисправностей при загрузке операционной системы на серверах без KVM — непростое занятие. Создаем себе KVM-over-IP через образ восстановления и виртуальную машину.
В случае возникновения проблем с операционной системой на удаленном сервере, администратор загружает образ восстановления и проводит необходимые работы. Такой способ отлично работает, когда причина сбоя известна, а образ восстановления и установленная на сервере операционная система из одного семейства. Если причина сбоя еще не известна, необходимо понаблюдать за ходом загрузки операционной системы.
Удаленный KVM
Получить доступ к консоли сервера можно с помощью встроенных средств, таких как IPMI или Intel® vPro™, или с помощью внешних устройств, именуемых IP-KVM. Существуют ситуации, в которых все из перечисленных технологий недоступны. Однако, это не конец. Если сервер можно удаленно перезагрузить в образ восстановления на базе операционной системы семейства Linux, то можно быстро организовать KVM-over-IP.
Образ восстановления представляет собой полноценную операционную систему, которая размещается в оперативной памяти. Таким образом, мы можем запускать любое программное обеспечение, в том числе и виртуальные машины (ВМ). То есть можно запустить ВМ, внутри которой будет работать операционная система сервера. Доступ к консоли ВМ может быть организован, например, через VNC.
Для запуска операционной системы сервера внутри ВМ необходимо указать диски сервера в качестве дисков ВМ. В операционных системах семейства Linux физические диски представляются блочными устройствами вида /dev/sdX, с которыми можно работать как с обычными файлами.
Некоторые гипервизоры, такие как QEMU и VirtualBox позволяют хранить данные ВМ в «сыром» виде, то есть только данные хранилища без метаданных гипервизора. Таким образом, ВМ можно запустить с использованием физических дисков сервера.
Подобный способ требует ресурсов на запуск образа восстановления и ВМ внутри него. Однако, при наличии четырех и более гигабайт оперативной памяти это не станет проблемой.
Подготовка окружения
В качестве виртуальной машины можно использовать легковесную и простую программу QEMU, которая чаще всего не является частью образа восстановления, поэтому должна быть установлена отдельно. Образ восстановления, который мы предлагаем клиентам, основан на Arch Linux, в котором используется пакетный менеджер pacman.
Сперва необходимо удостовериться, что образ восстановления использует последнии версии программного обеспечения. Выполнить проверку и обновить все компоненты ОС можно следующей командой:
После обновления необходимо установить QEMU. Команда на установку через pacman будет выглядеть так:
Проверим, что qemu установилась корректно:
# qemu-system-x86_64 —version
QEMU emulator version 4.0.0
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
Если все так, то образ восстановления готов к работе.
Запуск виртуальной машины
Сперва необходимо определиться с количеством ресурсов, выделяемых ВМ, и выяснить пути до физических дисков. В нашем случае мы выделим два ядра и два гигабайта оперативной памяти виртуальной машине, а диски находятся по пути /dev/sda и /dev/sdb. Запустим ВМ:
qemu-system-x86_64 \
-m 2048M \
-net nic -net user \
-enable-kvm \
-cpu host,nx \
-M pc \
-smp 2 \
-vga std \
-drive file=/dev/sda,format=raw,index=0,media=disk \
-drive file=/dev/sdb,format=raw,index=1,media=disk \
-vnc :0,password \
-monitor stdio
Немного подробнее о том, что значит каждый из параметров:
- -m 2048M — выделяем 2 ГБ оперативной памяти на ВМ;
- -net nic -net user — добавляем простое подключение к сети через гипервизор с использованием NAT (Network Address Translation);
- -enable-kvm — включаем полную виртуализацию KVM (Kernel Virtual Machine);
- -cpu host — говорим виртуальному процессору получить весь функционал процессора сервера;
- -M pc — тип оборудования PC;
- -smp 2 — виртуальный процессор должен быть двухъядерным;
- -vga std — выбираем стандартную видеокарту, которая не поддерживает большие разрешения экрана;
- -drive file=/dev/sda,format=raw,index=0,media=disk
- file=/dev/sdX — путь до блочного устройства, представляющего диск сервера;
- format=raw — помечаем, что в указанном файле все данные лежат в «сыром» виде, то есть как на диске;
- index=0 — номер диска, должен увеличиваться для каждого следующего диска на единицу;
- media=disk — виртуальная машина должна распознать это хранилище как диск;
- -vnc :0, password — запускаем VNC-сервер по умолчанию на 0.0.0.0:5900, в качестве авторизации используем пароль;
- -monitor stdio — общение администратора с qemu будет происходить через стандартные потоки ввода-вывода.
Если все в порядке, то запустится QEMU монитор:
QEMU 4.0.0 monitor — type ‘help’ for more information
(qemu)
Мы указали, что авторизация происходит по паролю, но не указали сам пароль. Сделать это можно отправив команду change vnc password в QEMU-монитор. Важное замечание: пароль не может быть больше восьми символов.
(qemu) change vnc password
Password: ******
После этого мы можем подключиться любым VNC-клиентом, например, Remmina, по IP-адресу нашего сервера с указанным нами паролем.
Теперь мы не только видим возможные ошибки на этапе загрузки, но и можем с ними бороться.
По окончании работ необходимо завершить виртуальную машину. Это можно сделать как внутри ОС, подав сигнал на выключение, либо дать команду system_powerdown в QEMU-монитор. Это будет эквивалентно однократному нажатию кнопки выключения: операционная система внутри виртуальной машины плавно завершится.
Установка операционной системы
Виртуальная машина имеет полный доступ к дискам сервера и потому может быть использована для установки операционной системы вручную. Единственное ограничение заключается в количестве оперативной памяти: не всегда ISO-образ можно разместить в оперативной памяти. Выделим в оперативной памяти четыре гигабайта для хранения образа в /mnt:
mount -t tmpfs -o size=4G tmpfs /mnt
Также загрузим установочный образ операционной системы FreeBSD 12.0:
wget -P /mnt ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-RELEASE-amd64-bootonly.iso
Теперь можно запускать ВМ:
qemu-system-x86_64 \
-m 2048M \
-net nic -net user \
-enable-kvm \
-cpu host,nx \
-M pc \
-smp 2 \
-vga std \
-drive file=/dev/sda,format=raw,index=0,media=disk \
-drive file=/dev/sdb,format=raw,index=1,media=disk \
-vnc :0,password \
-monitor stdio \
-cdrom /mnt/FreeBSD-12.0-RELEASE-amd64-bootonly.iso \
-boot d
Флаг -boot d устанавливает загрузку с CD-привода. Подключаемся VNC-клиентом и видим загрузчик FreeBSD.
Так как для доступа в интернет использовалось получение адреса по DHCP, возможно, после настройки будет необходимо загрузиться в только что установленную систему и исправить сетевые настройки. В некоторых случаях может потребоваться установка драйверов сетевого адаптера, так как сетевая карта, установленная в сервере и эмулируемая в ВМ отличаются.
Источник
Download QEMU
Source code
Grab the source code for the latest releases and compile it yourself! Detailed compilation instructions can be found in the wiki for Linux, Win32 and macOS.
- 6.1.0 Aug 24st 2021
signature — changes - 6.0.0 Apr 29th 2021
signature — changes - 5.2.0 Dec 8th 2020
signature — changes
or stay on the bleeding edge with the git repository!
Build instructions
To download and build QEMU 6.1.0:
To download and build QEMU from git:
The latest development happens on the master branch. The stable trees are located in branches named stable-X.YY branch, where X.YY is the release version.
Linux
QEMU is packaged by most Linux distributions:
Arch: pacman -S qemu
Debian/Ubuntu: apt-get install qemu
Fedora: dnf install @virtualization
Gentoo: emerge —ask app-emulation/qemu
RHEL/CentOS: yum install qemu-kvm
SUSE: zypper install qemu
macOS
QEMU can be installed from Homebrew:
QEMU can be installed from MacPorts:
QEMU requires Mac OS X 10.5 or later, but it is recommended to use Mac OS X 10.7 or later.
Windows
Stefan Weil provides binaries and installers for both 32-bit and 64-bit Windows.
Version numbering
Since version 3.0.0, QEMU uses a time based version numbering scheme:
major incremented by 1 for the first release of the year minor reset to 0 with every major increment, otherwise incremented by 1 for each release from git master micro always 0 for releases from git master, incremented by 1 for each stable branch release
The implication of this is that changes in major version number do not have any bearing on the scope of changes included in the release. Non-backward compatible changes may be made in any master branch release, provided they have followed the deprecation policy which calls for warnings to be emitted for a minimum of two releases prior to the change.
Источник
Общие принципы работы QEMU-KVM
Мое текущее понимание:
1) KVM
KVM (Kernel-based Virtual Machine) – гипервизор (VMM – Virtual Machine Manager), работающий в виде модуля на ОС Linux. Гипервизор нужен для того, чтобы запускать некий софт в несуществующей (виртуальной) среде и при этом, скрывать от этого софта реальное физическое железо, на котором этот софт работает. Гипервизор работает в роли «прокладки» между физическим железом (хостом) и виртуальной ОС (гостем).
Поскольку KVM является стандартным модулем ядра Linux, он получает от ядра все положенные ништяки (работа с памятью, планировщик и пр.). А соответственно, в конечном итоге, все эти преимущества достаются и гостям (т.к. гости работают на гипервизоре, которые работает на/в ядре ОС Linux).
KVM очень быстрый, но его самого по себе недостаточно для запуска виртуальной ОС, т.к. для этого нужна эмуляция I/O. Для I/O (процессор, диски, сеть, видео, PCI, USB, серийные порты и т.д.) KVM использует QEMU.
2) QEMU
QEMU (Quick Emulator) – эмулятор различных устройств, который позволяет запускать операционные системы, предназначенные под одну архитектуру, на другой (например, ARM –> x86). Кроме процессора, QEMU эмулирует различные периферийные устройства: сетевые карты, HDD, видео карты, PCI, USB и пр.
Работает это так:
Инструкции/бинарный код (например, ARM) конвертируются в промежуточный платформонезависимый код при помощи конвертера TCG (Tiny Code Generator) и затем этот платформонезависимый бинарный код конвертируется уже в целевые инструкции/код (например, x86).
ARM –> промежуточный_код –> x86
По сути, вы можете запускать виртуальные машины на QEMU на любом хосте, даже со старыми моделями процессоров, не поддерживающими Intel VT-x (Intel Virtualization Technology) / AMD SVM (AMD Secure Virtual Machine). Однако в таком случае, это будет работать весьма медленно, в связи с тем, что исполняемый бинарный код нужно перекомпилировать на лету два раза, при помощи TCG (TCG – это Just-in-Time compiler).
Т.е. сам по себе QEMU мега крутой, но работает очень медленно.
3) Protection rings
Бинарный программный код на процессорах работает не просто так, а располагается на разных уровнях (кольцах / Protection rings) с разными уровнями доступа к данным, от самого привилегированного (Ring 0), до самого ограниченного, зарегулированного и «с закрученными гайками» (Ring 3).
Операционная система (ядро ОС) работает на Ring 0 (kernel mode) и может делать с любыми данными и устройствами все, что угодно. Пользовательские приложения работают на уровне Ring 3 (user mode) и не в праве делать все, что захотят, а вместо этого каждый раз должны запрашивать доступ на проведение той или иной операции (таким образом, пользовательские приложения имеют доступ только к собственным данным и не могут «влезть» в «чужую песочницу»). Ring 1 и 2 предназначены для использования драйверами.
До изобретения Intel VT-x / AMD SVM, гипервизоры работали на Ring 0, а гости работали на Ring 1. Поскольку у Ring 1 недостаточно прав для нормального функционирования ОС, то при каждом привилегированном вызове от гостевой системы, гипервизору приходилось на лету модифицировать этот вызов и выполнять его на Ring 0 (примерно так, как это делает QEMU). Т.е. гостевой бинарный код НЕ выполнялся напрямую на процессоре, а каждый раз на лету проходил несколько промежуточных модификаций.
Накладные расходы были существенными и это было большой проблемой и тогда производители процессоров, независимо друг от друга, выпустили расширенный набор инструкций (Intel VT-x / AMD SVM), позволяющих выполнять код гостевых ОС НАПРЯМУЮ на процессоре хоста (минуя всякие затратные промежуточные этапы, как это было раньше).
С появлением Intel VT-x / AMD SVM, был создан специальный новый уровень Ring -1 (минус один). И теперь на нем работает гипервизор, а гости работают на Ring 0 и получают привилегированный доступ к CPU.
- хост работает на Ring 0
- гости работают на Ring 0
- гипервизор работает на Ring -1
4) QEMU-KVM
KVM предоставляет доступ гостям к Ring 0 и использует QEMU для эмуляции I/O (процессор, диски, сеть, видео, PCI, USB, серийные порты и т.д., которые «видят» и с которыми работают гости).
Отсюда QEMU-KVM (или KVM-QEMU) 🙂
P.S. Текст этой статьи изначально был опубликован в Telegram канале @RU_Voip в качестве ответа на вопрос одного из участников канала.
Напишите в комментариях, в каких местах я не правильно понимаю тему или если есть, что дополнить.
Источник
