Меню Рубрики

Установка qemu в archlinux

Как пользоваться qemu

Преимущество виртуализации в том, что она позволяет запустить на одном компьютере несколько разных операционных систем на одном компьютере одновременно и при этом неважно какой они будут архитектуры. Среди домашних пользователей достаточно часто используются такие программы для эмуляции компьютера, как Virtualbox и VMware, это мощные программы с графическим интерфейсом и множеством возможностей, которые очень просто настроить.

Но существуют и другие решения, которые дают больше контроля над процессом виртуализации и при этом более сложны. Один из таких инструментов — qemu. В этой инструкции мы рассмотрим что такое qemu и как пользоваться qemu для виртуализации, кроме того, разберем его преимущества над другими программами.

Что такое qemu?

Qemu — это бесплатный инструмент с открытым исходным кодом для эмуляции и виртуализации работы операционных систем на компьютере. Программа может работать в Windows, Linux, MacOS и даже на Android. Ресурсы хоста, такие как процессор, жесткий диск, память, разделяются между виртуальными машинами.

Qemu использует аппаратную виртуализацию, поэтому может выполнять гостевые операционные системы почти так же быстро, как и на основном железе. Может использоваться гипервизор XEN или модуль ядра KVM в Linux. Qemu может работать в двух режимах работы:

  • Полная эмуляция системы — в этом режиме qemu полностью эмулирует устройство, например, компьютер, включая все его компоненты, процессор и различные периферийные устройства. Он может использоваться для запуска нескольких операционных систем без перезагрузки или отладки системного кода.
  • Эмуляция пользовательского режима — работает только для Linux хоста, позволяет запускать процессы Linux, скомпилированные для одной архитектуры в другой, например, ARM программы в x86. Полезно для разработки, кросс-компиляции и отладки.

Эмулировать можно такие архитектуры: x86 (32 и 64 бит), PowerPC (32 и 64 бит), ARM, MIPS (32 бит), Sprac (32 и 64 бит), Alpha, ColdFire(m68k), CRISv2 и MicroBlaze. Этот список уже более внушительный чем у Virtualbox.

Установка qemu

Перед тем как мы сможем использовать программу, необходимо ее установить. Если вы используете дистрибутив Linux, например, Ubuntu, то сможете найти программу в официальных репозиториях. Для Ubuntu команда будет выглядеть вот так:

sudo apt install qemu-kvm qemu

Для Fedora и других систем RedHat можно установить группу Virtualization:

sudo dnf install @virtualization

В ArchLinux используйте Pacman:

Для Windows или MacOS вам нужно скачать исполняемый файл из официального сайта. Программа управляется только через терминал, так что вы главном меню системы ничего не появиться после установки. А теперь перейдем к тому как настроить qemu.

Как пользоваться qemu?

Теперь, когда программа установлена и готова к использованию попытаемся разобраться как ее запустить и применять. Но сначала нужно разобраться какие команды и для чего используются. Эмулятор qemu создает много команд, но их можно разделить на группы:

  • qemu-архитектура — эмуляция окружения пользователя для указанной архитектуры;
  • qemu-system-архитектура — эмуляция полной системы для архитектуры;
  • qemu-img — утилита для работы с дисками;
  • qemu-io — утилита для работы с вводом/выводом на диск;
  • qemu-user — оболочка для qemu-архитектура, позволяет запускать программы других архитектур в этой системе;
  • qemu-system — оболочка для qemu-system-архитектура, позволяет полностью эмулировать систему нужной архитектуры.

Сначала разберемся с эмуляцией полной системы, поскольку для решения этой задачи виртуальная машина qemu используется чаще всего, а уже потом перейдем к режиму пользователя.

1. Использование qemu-system

Чтобы вы понимали что и откуда берется для начала рассмотрим опции утилиты qemu-system. Синтаксис команды такой:

$ qemu-system параметры

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

-имя_параметра имя_опции = значение : значение2

Мы рассмотрим только основные параметры, и их опции, которые нам понадобятся:

  • -machine указывает тип компьютера, который вы собрались эмулировать, можно выбрать ubuntu, pc, pc-q35 и другие варианты, смотрите подробнее командой -machine help;
  • -cpu — тип процессора, можно передать непосредственно тип процессора, а также дополнительные флаги;
  • -smp — включает симуляцию мультипроцессорной архитектуры;
  • -boot — позволяет настроить порядок загрузки устройств, a,b — дискета, с — первый жесткий диск, d — CDROM, n-p — загрузка через сеть, по умолчанию виртуальная машина загружается из жесткого диска;
  • -m — указывает количество оперативной памяти, доступной машине;
  • -k — раскладка клавиатуры по умолчанию;
  • -soundhw — подключить звуковую карту к системе;
  • -device — подключить указанное устройство к машине, нужно указать драйвер и его опции;
  • -name — имя гостевой системы, будет отображаться в верху окна;
  • -uu >

Мы рассмотрели опции для qemu-system-x86-64, для других архитектур, они могут немного отличаться. А теперь разберем несколько простых примеров как использовать qemu, как создать машину qemu и настроить ее.

Сначала нужно создать жесткий диск для установки. Вы можете использовать реальные жесткие диски, но работать с образами намного удобнее. Можно просто создать пустой файл, заполненный нулями, а затем форматировать его в нужную файловую систему во время установки, но также можно создать файл формата qcow2, этот формат используется по умолчанию в qemu. Воспользуемся командой qemu-img:

qemu-img create -f qcow2 ubuntu.qcow 10G

Опция -f указывает формат нового файла. Теперь мы можем непосредственно перейти к запуску qemu-system. Вот так будет выглядеть самая простая команда запуска системы:

qemu-system-x86_64 -hda ubuntu.qcow -boot d -cdrom

/downloads/ubuntu-17.04-server-amd64.iso -m 640

Здесь мы подключаем наш жесткий диск как hda, затем указываем что нужно загружаться с cdrom и подключаем образ системы ubuntu к нему. Последний параметр указывает сколько оперативной памяти будет выделено для машины.

Дальше откроется окно, похожее на VritualBox и начнется установка системы. После того как установка будет завершена, вы сможете запускать машину командой:

qemu-system-x86_64 -hda ubuntu.img -m 640

Создавать виртуальную машину с другой архитектурой не очень сложно, достаточно изменить команду. Например, сделаем виртуальную машину ppc:

qemu-system-ppc -hda ubuntu.qcow -boot d -cdrom

/downloads/ubuntu-17.04-server-amd64.iso -m 640

Поскольку сейчас мы не используем kvm, то система будет работать очень медленно все можно очень сильно ускорить, если его включить с помощью опции -enable-kvm:

qemu-system-x86_64 -hda ubuntu.qcow -m 640 -enable-kvm

По умолчанию в гостевой системе не будет звука, но вы можете подключить туда звуковую карту:

qemu-system-x86_64 -hda ubuntu.qcow -m 640 -enable-kvm -soundhw ac97

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

qemu-system-x86_64 -hda ubuntu.qcow -m 640 -enable-kvm -soundhw ac97 -vga qxl

С помощью опции -global qxl-vga.vram_size можно задать объем видеопамяти, доступный машине, значение указывается в байтах, например:

qemu-system-x86_64 -hda ubuntu.qcow -m 640 -enable-kvm -soundhw ac97 -vga qxl -global qxl-vga.vram_size=4294967

Для многих машин важно чтобы из них был доступ в сеть интернет. Настройка сети qemu — это достаточно обширная тема, которую мы не будем полностью раскрывать в этой статье. Если кратко, то, в qemu используется специальный виртуальный шлюз vlan, который позволяет соединять машины с внешней сетью или между собой. Каждый vlan имеет свой номер. Самый простой способ настроить сеть — использовать такие параметры:

qemu-system-x86_64 -hda ubuntu.qcow -m 640 -enable-kvm -net nic,vlan=0 -net user,vlan=0

Здесь мы два раза вызываем опцию -net, в первый раз создаем виртуальную сетевую карту с помощью параметра -nic и подключаем ее к vlan с номером 0. Вторая же опция -net создает наш vlan 0 с типом конфигурации user, которая не требует дополнительной настройки и автоматически подключается к сети хоста.

2. Использование эмуляции окружения

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

Точно так же вы можете выполнить arm программу или программу для любой из поддерживаемых архитектур.

Выводы

В этой статье мы очень кратко рассмотрели как пользоваться qemu, основные настройки этой утилиты и опции. На самом деле там намного больше опций и возможностей. Одна только возможность эмулировать такое огромное количество архитектур чего стоит. Если для вас эмулятор qemu слишком сложен через терминал, то можно использовать графический интерфейс, например, virt-manager. А вы используете qemu? Или предпочитаете другие виртуальные машины? Почему? Напишите в комментариях!

источник

QEMU (Русский)

Эта страница нуждается в сопроводителе

Эта статья или раздел нуждается в переводе

Согласно странице о QEMU, «QEMU — универсальный с открытым исходным кодом эмулятор и виртуализатор.»

При использовании в качестве машинного эмулятора QEMU может запускать ОС и программы созданные для одной платформы (например для плат ARM) на других (например, на вашем ПК x86). Эмуляция происходит с хорошей производительностью, благодаря использованию динамической трансляции.

QEMU может использовать другие гипервизоры, такие как Xen или KVM, для использования расширений ЦП (HVM) для виртуализации. При использовании в качестве виртуализатора QEMU достигает производительность схожую с нативной путем исполнения гостевого кода напрямую на ЦП хост-ситемы.

Contents

Установка

Установите пакет qemu (или qemu-headless для версии без графического интерфейса пользователя) и необходимые вам дополнительные пакеты, перечисленные ниже:

Графические интерфейсы для QEMU

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

Libvirt предоставляет удобный способ управления виртуальными машинами QEMU. Для получения списка доступных графических интерфейсов смотрите список клиентов libvirt.

Другие графические интерфейсы для QEMU:

Создание новой виртуальной машины

Создание образа жесткого диска

The factual accuracy of this article or section is disputed.

Чтобы запустить QEMU вам нужен образ жесткого диск, конечно, если вы не запускаете live систему через CD-ROM или сеть (и при этом ничего не делаете для установки операционной системы на образ диска). Образ жесткого диска — файл, хранящий содержимое эмулируемого жесткого диска.

Формат образа жесткого диска может быть raw’, так что он буквально одинаков побайтно по сравнению с тем, что отображается в госте. Он всегда будет использовать полную емкость гостевого жесткого диска на хосте. Этот способ обеспечивает наименьшие издержки ввода-вывода, но может занимать много места, поскольку неиспользуемое пространство в гостевой системе не может использоваться на хосте.

Кроме того, формат образа жесткого диска может быть таким как, qcow2, в котором выделяется пространство файлу образа только, когда гостевая операционная система фактически записывает эти сектора на своем виртуальном жестком диске. В гостевой системе отображается фактический размер образа, хотя на хост-системе он может занимать только очень небольшое пространство. Этот формат также поддерживает функцию снимков экрана (для получения дополнительной информации смотрите #Creating and managing snapshots via the monitor console). Но использование этого формата вместо raw может сказаться на производительности.

QEMU предоставляет команду qemu-img для создания образов жесткого диска. Например, чтобы создать образ с размером 4 Гб в формате raw, нужно выполнить:

Вы можете использовать -f qcow2 для создания диска qcow2.

Оверлейное хранилище изображений

Вы можете создать образ хранилища один раз (‘backing’ изображение), и QEMU сохранит изменения этого изображения в оверлейном изображении. Это позволяет вам вернуться к предыдущему состоянию этого образа. Вы можете вернуться, создав новое оверлейное изображение в то время, когда вы хотите восстановить его, основываясь на исходном backing изображении.

Чтобы создать оверлейное изображение, введите команду:

После этого вы можете запускать виртуальную машину QEMU как обычно (см. #Running virtualized system [broken link: invalid section] ):

Дальше backing изображение останется без изменений, и изменения в этом хранилище будут записаны в файл оверлейного изображения.

Если путь к фоновому изображению изменяется, требуется ремонт.

Убедитесь, что путь к исходному backing изображению существует. При необходимости сделайте символическую ссылку на исходный путь. Затем выполните команду так:

На ваше усмотрение вы можете альтернативно выполнить «небезопасную» перебазировку, когда старый путь к резервному изображению не проверен:

Изменение размера образа

Исполняемый файл qemu-img имеет параметр resize , который позволяет легко изменить размер образа жесткого диска. Это работает для образов raw и qcow2. Например, чтобы увеличить пространство образа на 10 ГБ, выполните:

После увеличения, вы должны использовать файловую систему и инструменты разметки внутри виртуальной машины, чтобы начать использовать новое пространство. При сжатии образа диска вы должны сначала уменьшить выделенные файловые системы и размеры разделов, используя файловую систему и инструменты разбиения на виртуальной машине, а затем соответственно уменьшить размер образа диска, иначе сжатие образа диска приведет к потери данных!

Преобразование образа

Вы можете преобразовать образ в другие форматы, используя qemu-img convert . Этот пример показывает как конвертировать образ raw в qcow2:

Это не удаляет изначальный образ.

Подготовка установочного носителя

Чтобы установить операционную систему на ваш образ диска, вам нужен установочный носитель (например, оптический диск, флешка USB или образ ISO) с ней. Не нужно его монтировать, потому что QEMU напрямую обращается к нему.

Установка операционной системы

Это первый раз, когда вам нужно будет запустить эмулятор. Для установки операционной системы на образ диска, вы должны подключить образ диска и установочный носитель к виртуальной машине и загрузить его с установочного носителя.

Например, для гостевой системы i386 для установки из загрузочного файла ISO в качестве CD-ROM и образа диска raw, необходимо выполнить:

Для получения дополнительной информации о загрузке с других типов носителей (например, дискет, образов дисков или физических дисков) смотрите qemu(1) и смотрите #Запуск виртуальной машины, чтобы узнать другие полезные параметры.

После завершения установки операционной системы, образ QEMU может быть загружен напрямую (смотрите #Запуск виртуальной машины).

Запуск виртуальной машины

Двоичные файлы qemu-system-* (например, qemu-system-i386 или qemu-system-x86_64 в зависимости от архитектуры гостя) используются для запуска ВМ. Использование:

Параметры одинаковы для всех двоичных файлов qemu-system-* , посмотрите документацию qemu(1) , чтобы узнать все доступные параметры.

По умолчанию QEMU показывает виртуальную машину в отдельном окне. Поэтому нужно помнить о одной вещи: когда вы нажимаете внутри окна QEMU, курсор мыши захватывается. Чтобы отпустить его, нажмите Ctrl+Alt+g .

Включение KVM

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

Чтобы запустить QEMU в режиме KVM, добавьте -enable-kvm к дополнительным параметрам запуска. Для проверки работоспособности KVM для запущенной ВМ войдите в Монитор QEMU с помощью сочетания клавиш Ctrl+Alt+Shift+2 и там введите info kvm .

Включение поддержки IOMMU (Intel VT-d/AMD-Vi)

Сначала включите IOMMU, для получения дополнительной информации смотрите PCI passthrough via OVMF#Setting up IOMMU.

Для создания устройства IOMMU добавьте -device intel-iommu :

На системах с ЦП Intel создание устройства IOMMU в госте QEMU с параметром -device intel-iommu приведет к отключению PCI passthrough с ошибкой наподобие этой:

Добавление параметра ядра intel_iommu=on , пока все еще необходимо для переназначения ввода-вывода (например PCI passthrough с vfio-pci). Если PCI passthrough необходим, не используйте параметр -device intel-iommu .

Перемещение данных между хостом и гостевой ОС

Данные могут быть разделены между хостом и гостевой ОС, используя любой сетевой протокол, который может передавать файлы, такие как NFS, SMB, NBD, HTTP, FTP, or SSH, при условии, что вы правильно настроили сеть и включили соответствующие службы.

Сеть в пользовательском режиме по умолчанию позволяет гостевой системе получить доступ к ОС хоста по IP-адресу 10.0.2.2. Любые серверы, которые вы используете в своей операционной системе, такие как сервер SSH или SMB, будут доступны по этому IP-адресу. Таким образом, на гостевой ОС вы можете смонтировать каталоги, экспортированные на хост через SMB или NFS, или вы можете получить доступ к HTTP-серверу хоста и т.д.

Хост-ОС не сможет получить доступ к серверам, работающим на гостевой ОС, но это может быть сделано с другими сетевыми конфигурациями (см. #Tap networking with QEMU).

Встроенный SMB-сервер QEMU

QEMU’s documentation says it has a «built-in» SMB server, but actually it just starts up Samba with an automatically generated smb.conf file located at /tmp/qemu-smb.pid-0/smb.conf and makes it accessible to the guest at a different IP address (10.0.2.4 by default). This only works for user networking, and this is not necessarily very useful since the guest can also access the normal Samba service on the host if you have set up shares on it.

To enable this feature, start QEMU with a command like:

where shared_dir_path is a directory that you want to share between the guest and host.

Then, in the guest, you will be able to access the shared directory on the host 10.0.2.4 with the share name «qemu». For example, in Windows Explorer you would go to \\10.0.2.4\qemu .

Монтирование раздела внутри образа raw диска

Когда виртуальная машина не работает, можно смонтировать разделы, которые находятся внутри файла образа raw диска, настроив их в качестве устройств обратной связи. Это не работает с образами дисков в специальных форматах, таких как qcow2, хотя их можно смонтировать с помощью qemu-nbd .

С указанием байтового смещения вручную

Один из способов смонтировать раздел образа диска — это смонтировать образ диска с определенным смещением, используя следующую команду:

Параметр offset=32256 фактически передается программе losetup для настройки устройства loopback, которое начинается с 32256 байтового смещения и продолжается до конца. Это loopback устройство затем монтируется. Вы также можете использовать опцию sizelimit , чтобы указать точный размер раздела, но это обычно не требуется.

В зависимости от образа диска необходимый раздел может не начинаться со смещения 32256. Запустите fdisk -l disk_image , чтобы увидеть разделы в образе. fdisk делает начальное и конечное смещения в 512-байтовых секторах, поэтому умножьте на 512, чтобы получить правильное смещение для передачи в mount .

С loop модулем автоопределение разделов

Драйвер loop Linux поддерживает разделы в устройствах loopback, но по умолчанию он отключен. Чтобы включить его, сделайте следующее:

  • Избавьтесь от всех ваших loopback устройств (размонтируйте все подключенные образы и т.д.).
  • Загрузить модуль ядра loop и загрузите его с набором параметров max_part=15 . Кроме того, максимальное количество loop устройств можно контролировать с помощью параметра max_loop .

Настройте свое изображение в качестве loopback устройства:

Затем, если созданным устройством было /dev/loop0 , автоматически будут созданы дополнительные устройства /dev/loop0pX , где X — номер раздела. Эти устройства с loopback можно монтировать напрямую.

Чтобы смонтировать образ диска с помощью udisksctl, см. Udisks#Mount loop devices.

С kpartx

kpartx из пакета multipath-tools может прочитать таблицу разделов на устройстве и создать новое устройство для каждого раздела.

Это настроит устройство обратной связи и создаст необходимое устройство(а) раздел(ов) в /dev/mapper/ .

Монтирование раздела внутри образа qcow2

Вы можете смонтировать раздел внутри образа qcow2, используя qemu-nbd . See Wikibooks.

Использование любого реального раздела в качестве единственного основного раздела образа жесткого диска

Иногда вы можете захотеть использовать один из ваших системных разделов внутри QEMU. Использование raw раздела для виртуальной машины повысит производительность, поскольку операции чтения и записи не проходят уровень файловой системы на физическом хосте. Такой раздел также обеспечивает возможность обмена данными между хостом и гостем.

В Arch Linux файлы устройств для raw разделов по умолчанию принадлежат root и группе disk. Если вы хотите, чтобы пользователь без полномочий root мог читать и записывать в необработанный раздел, вам нужно изменить владельца файла устройства раздела на этого пользователя.

После этого вы можете присоединить раздел к виртуальной машине QEMU как виртуальный диск.

Однако все немного сложнее, если вы хотите, чтобы «вся» виртуальная машина содержалась в разделе. В этом случае не будет никакого файла образа диска для фактической загрузки виртуальной машины, поскольку вы не можете установить загрузчик на раздел, который сам отформатирован как файловая система, а не как устройство с разделами MBR. Такая виртуальная машина может быть загружена либо путем указания kernel и initrd вручную, либо путем моделирования диска с MBR с использованием линейного RAID.

Указываем ядро и initrd вручную

QEMU поддерживает загрузку Linux kernels и init ramdisks напрямую, обходя таким образом загрузчики, такие как GRUB. Затем он может быть запущен с физическим разделом, содержащим корневую файловую систему в качестве виртуального диска, который не будет выглядеть как разделенный. Это делается с помощью команды, аналогичной следующей:

В приведенном выше примере с физическим разделом, используемым для корневой файловой системы гостя, является /dev/sda3 на хосте, но на госте он будет отображается как /dev/sda .

Вы можете указать любое ядро и initrd, а не только те, которые поставляются с Arch Linux.

Когда есть несколько kernel parameters, которые нужно передать в опцию -append , они должны быть заключены в одинарные или двойные кавычки.

Имитация виртуального диска с MBR с использованием линейного RAID

A more complicated way to have a virtual machine use a physical partition, while keeping that partition formatted as a file system and not just having the guest partition the partition as if it were a disk, is to simulate a MBR for it so that it can boot using a bootloader such as GRUB.

You can do this using software RAID in linear mode (you need the linear.ko kernel driver) and a loopback device: the trick is to dynamically prepend a master boot record (MBR) to the real partition you wish to embed in a QEMU raw disk image.

Suppose you have a plain, unmounted /dev/hdaN partition with some file system on it you wish to make part of a QEMU disk image. First, you create some small file to hold the MBR:

Here, a 16 KB (32 * 512 bytes) file is created. It is important not to make it too small (even if the MBR only needs a single 512 bytes block), since the smaller it will be, the smaller the chunk size of the software RAID device will have to be, which could have an impact on performance. Then, you setup a loopback device to the MBR file:

Let us assume the resulting device is /dev/loop0 , because we would not already have been using other loopbacks. Next step is to create the «merged» MBR + /dev/hdaN disk image using software RAID:

The resulting /dev/md0 is what you will use as a QEMU raw disk image (do not forget to set the permissions so that the emulator can access it). The last (and somewhat tricky) step is to set the disk configuration (disk geometry and partitions table) so that the primary partition start point in the MBR matches the one of /dev/hdaN inside /dev/md0 (an offset of exactly 16 * 512 = 16384 bytes in this example). Do this using fdisk on the host machine, not in the emulator: the default raw disc detection routine from QEMU often results in non-kilobyte-roundable offsets (such as 31.5 KB, as in the previous section) that cannot be managed by the software RAID code. Hence, from the the host:

Press X to enter the expert menu. Set number of ‘s’ectors per track so that the size of one cylinder matches the size of your MBR file. For two heads and a sector size of 512, the number of sectors per track should be 16, so we get cylinders of size 2x16x512=16k.

Now, press R to return to the main menu.

Press P and check that the cylinder size is now 16k.

Now, create a single primary partition corresponding to /dev/hdaN . It should start at cylinder 2 and end at the end of the disk (note that the number of cylinders now differs from what it was when you entered fdisk.

Finally, ‘w’rite the result to the file: you are done. You now have a partition you can mount directly from your host, as well as part of a QEMU disk image:

You can, of course, safely set any bootloader on this disk image using QEMU, provided the original /dev/hdaN partition contains the necessary tools.

Альтернатива: использовать nbd-сервер

Вместо линейного RAID вы можете использовать nbd-server (из пакета nbd ) для создания оболочки MBR для QEMU.

Предполагая, что вы уже настроили файл-оболочку MBR, как описано выше, переименуйте его в wrapper.img.0 . Затем создайте символическую ссылку с именем wrapper.img.1 в том же каталоге, указывая на ваш раздел. Затем поместите следующий скрипт в тот же каталог:

Суффиксы .0 and .1 необходимы; остальное можно изменить. После запуска приведенного выше сценария (который может потребоваться запустить от имени пользователя root, чтобы nbd-сервер мог получить доступ к разделу), вы можете запустить QEMU с помощью:

Сетевые топологии

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Производительность виртуальных сетей должна быть лучше с устройствами и мостами(bridges), подключенными к сети, чем с сетью в пользовательском режиме или vde, потому что устройства и мосты с поддержкой сети реализованы в ядре.

Кроме того, производительность сети можно улучшить, назначив виртуальным машинам сетевое устройство virtio, а не эмуляцию по умолчанию для сетевой карты e1000. См. #Installing virtio drivers для получения дополнительной информации.

Предупреждение об уровне адресации

By giving the -net nic argument to QEMU, it will, by default, assign a virtual machine a network interface with the link-level address 52:54:00:12:34:56 . However, when using bridged networking with multiple virtual machines, it is essential that each virtual machine has a unique link-level (MAC) address on the virtual machine side of the tap device. Otherwise, the bridge will not work correctly, because it will receive packets from multiple sources that have the same link-level address. This problem occurs even if the tap devices themselves have unique link-level addresses because the source link-level address is not rewritten as packets pass through the tap device.

Make sure that each virtual machine has a unique link-level address, but it should always start with 52:54: . Use the following option, replace X with arbitrary hexadecimal digit:

Generating unique link-level addresses can be done in several ways:

  1. Manually specify unique link-level address for each NIC. The benefit is that the DHCP server will assign the same IP address each time the virtual machine is run, but it is unusable for large number of virtual machines.
  2. Generate random link-level address each time the virtual machine is run. Practically zero probability of collisions, but the downside is that the DHCP server will assign a different IP address each time. You can use the following command in a script to generate random link-level address in a macaddr variable:
  3. Use the following script qemu-mac-hasher.py to generate the link-level address from the virtual machine name using a hashing function. Given that the names of virtual machines are unique, this method combines the benefits of the aforementioned methods: it generates the same link-level address each time the script is run, yet it preserves the practically zero probability of collisions.

In a script, you can use for example:

Пользовательский режим сети

By default, without any -netdev arguments, QEMU will use user-mode networking with a built-in DHCP server. Your virtual machines will be assigned an IP address when they run their DHCP client, and they will be able to access the physical host’s network through IP masquerading done by QEMU.

This default configuration allows your virtual machines to easily access the Internet, provided that the host is connected to it, but the virtual machines will not be directly visible on the external network, nor will virtual machines be able to talk to each other if you start up more than one concurrently.

QEMU’s user-mode networking can offer more capabilities such as built-in TFTP or SMB servers, redirecting host ports to the guest (for example to allow SSH connections to the guest) or attaching guests to VLANs so that they can talk to each other. See the QEMU documentation on the -net user flag for more details.

However, user-mode networking has limitations in both utility and performance. More advanced network configurations require the use of tap devices or other methods.

Tap networking with QEMU

Tap devices are a Linux kernel feature that allows you to create virtual network interfaces that appear as real network interfaces. Packets sent to a tap interface are delivered to a userspace program, such as QEMU, that has bound itself to the interface.

QEMU can use tap networking for a virtual machine so that packets sent to the tap interface will be sent to the virtual machine and appear as coming from a network interface (usually an Ethernet interface) in the virtual machine. Conversely, everything that the virtual machine sends through its network interface will appear on the tap interface.

Tap devices are supported by the Linux bridge drivers, so it is possible to bridge together tap devices with each other and possibly with other host interfaces such as eth0 . This is desirable if you want your virtual machines to be able to talk to each other, or if you want other machines on your LAN to be able to talk to the virtual machines.

As indicated in the user-mode networking section, tap devices offer higher networking performance than user-mode. If the guest OS supports virtio network driver, then the networking performance will be increased considerably as well. Supposing the use of the tap0 device, that the virtio driver is used on the guest, and that no scripts are used to help start/stop networking, next is part of the qemu command one should see:

But if already using a tap device with virtio networking driver, one can even boost the networking performance by enabling vhost, like:

Host-only networking

If the bridge is given an IP address and traffic destined for it is allowed, but no real interface (e.g. eth0 ) is connected to the bridge, then the virtual machines will be able to talk to each other and the host system. However, they will not be able to talk to anything on the external network, provided that you do not set up IP masquerading on the physical host. This configuration is called host-only networking by other virtualization software such as VirtualBox.

Internal networking

If you do not give the bridge an IP address and add an iptables rule to drop all traffic to the bridge in the INPUT chain, then the virtual machines will be able to talk to each other, but not to the physical host or to the outside network. This configuration is called internal networking by other virtualization software such as VirtualBox. You will need to either assign static IP addresses to the virtual machines or run a DHCP server on one of them.

By default iptables would drop packets in the bridge network. You may need to use such iptables rule to allow packets in a bridged network:

Bridged networking using qemu-bridge-helper

This method does not require a start-up script and readily accommodates multiple taps and multiple bridges. It uses /usr/lib/qemu/qemu-bridge-helper binary, which allows creating tap devices on an existing bridge.

First, create a configuration file containing the names of all bridges to be used by QEMU:

Now start the VM. The most basic usage would be:

With multiple taps, the most basic usage requires specifying the VLAN for all additional NICs:

Creating bridge manually

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

The following describes how to bridge a virtual machine to a host interface such as eth0 , which is probably the most common configuration. This configuration makes it appear that the virtual machine is located directly on the external network, on the same Ethernet segment as the physical host machine.

We will replace the normal Ethernet adapter with a bridge adapter and bind the normal Ethernet adapter to it.

  • Install bridge-utils , which provides brctl to manipulate bridges.
  • Enable IPv4 forwarding:

To make the change permanent, change net.ipv4.ip_forward = 0 to net.ipv4.ip_forward = 1 in /etc/sysctl.d/99-sysctl.conf .

  • Load the tun module and configure it to be loaded on boot. See Kernel modules for details.
  • Now create the bridge. See Bridge with netctl for details. Remember to name your bridge as br0 , or change the scripts below to your bridge’s name.
  • Create the script that QEMU uses to bring up the tap adapter with root:kvm 750 permissions:
  • Create the script that QEMU uses to bring down the tap adapter in /etc/qemu-ifdown with root:kvm 750 permissions:
  • Use visudo to add the following to your sudoers file:
  • You launch QEMU using the following run-qemu script:

Then to launch a VM, do something like this

  • It is recommended for performance and security reasons to disable the firewall on the bridge:

Run sysctl -p /etc/sysctl.d/10-disable-firewall-on-bridge.conf to apply the changes immediately.

See the libvirt wiki and Fedora bug 512206. If you get errors by sysctl during boot about non-existing files, make the bridge module load at boot. See Kernel modules#Automatic module handling [broken link: invalid section] .

Alternatively, you can configure iptables to allow all traffic to be forwarded across the bridge by adding a rule like this:

Network sharing between physical device and a Tap device through iptables

Bridged networking works fine between a wired interface (Eg. eth0), and it is easy to setup. However if the host gets connected to the network through a wireless device, then bridging is not possible.

One way to overcome that is to setup a tap device with a static IP, making linux automatically handle the routing for it, and then forward traffic between the tap interface and the device connected to the network through iptables rules.

There you can find what is needed to share the network between devices, included tap and tun ones. The following just hints further on some of the host configurations required. As indicated in the reference above, the client needs to be configured for a static IP, using the IP assigned to the tap interface as the gateway. The caveat is that the DNS servers on the client might need to be manually edited if they change when changing from one host device connected to the network to another.

To allow IP forwarding on every boot, one need to add the following lines to sysctl configuration file inside /etc/sysctl.d :

The iptables rules can look like:

The prior supposes there are 3 devices connected to the network sharing traffic with one internal device, where for example:

The prior shows a forwarding that would allow sharing wired and wireless connections with the tap device.

The forwarding rules shown are stateless, and for pure forwarding. One could think of restricting specific traffic, putting a firewall in place to protect the guest and others. However those would decrease the networking performance, while a simple bridge does not include any of that.

Bonus: Whether the connection is wired or wireless, if one gets connected through VPN to a remote site with a tun device, supposing the tun device opened for that connection is tun0, and the prior iptables rules are applied, then the remote connection gets also shared with the guest. This avoids the need for the guest to also open a VPN connection. Again, as the guest networking needs to be static, then if connecting the host remotely this way, one most probably will need to edit the DNS servers on the guest.

Networking with VDE2

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

What is VDE?

VDE stands for Virtual Distributed Ethernet. It started as an enhancement of uml_switch. It is a toolbox to manage virtual networks.

The idea is to create virtual switches, which are basically sockets, and to «plug» both physical and virtual machines in them. The configuration we show here is quite simple; However, VDE is much more powerful than this, it can plug virtual switches together, run them on different hosts and monitor the traffic in the switches. You are invited to read the documentation of the project.

The advantage of this method is you do not have to add sudo privileges to your users. Regular users should not be allowed to run modprobe.

Basics

VDE support can be installed via the vde2 package.

In our config, we use tun/tap to create a virtual interface on my host. Load the tun module (see Kernel modules for details):

Now create the virtual switch:

This line creates the switch, creates tap0 , «plugs» it, and allows the users of the group users to use it.

The interface is plugged in but not configured yet. To configure it, run this command:

Now, you just have to run KVM with these -net options as a normal user:

Configure networking for your guest as you would do in a physical network.

Startup scripts

Example of main script starting VDE:

Example of systemd service using the above script:

Change permissions for qemu-network-env to be executable

You can start qemu-network-env.service as usual.

Alternative method

If the above method does not work or you do not want to mess with kernel configs, TUN, dnsmasq, and iptables you can do the following for the same result.

Then, to start the VM with a connection to the network of the host:

VDE2 Bridge

Based on quickhowto: qemu networking using vde, tun/tap, and bridge graphic. Any virtual machine connected to vde is externally exposed. For example, each virtual machine can receive DHCP configuration directly from your ADSL router.

Basics

Remember that you need tun module and bridge-utils package.

Create the vde2/tap device:

And configure bridge interface:

Startup scripts

All devices must be set up. And only the bridge needs an IP address. For physical devices on the bridge (e.g. eth0 ), this can be done with netctl using a custom Ethernet profile with:

The following custom systemd service can be used to create and activate a VDE2 tap interface for use in the users user group.

And finally, you can create the bridge interface with netctl.

Shorthand configuration

If you’re using QEMU with various networking options a lot, you probably have created a lot of -netdev and -device argument pairs, which gets quite repetitive. You can instead use the -nic argument to combine -netdev and -device together, so that, for example, these arguments:

Notice the lack of network IDs, and that the device was created with model=. . The first half of the -nic parameters are -netdev parameters, whereas the second half (after model=. ) are related with the device. The same parameters (for example, smb=. ) are used. There’s also a special parameter for -nic which completely disables the default (user-mode) networking:

See QEMU networking documentation for more information on parameters you can use.

Графика

QEMU может использовать следующие различные графические выходные данные: std , qxl , vmware , virtio , cirrus и none .

С -vga std вы можете получить разрешение до 2560 x 1600 пикселей без использования гостевых драйверов. Это значение по умолчанию, начиная с QEMU 2.2.

QXL — это виртуальный графический драйвер с поддержкой 2D. Чтобы использовать его, передайте параметр -vga qxl и установите драйверы в гостевой системе. Возможно, вы захотите использовать SPICE для улучшения графической производительности при использовании QXL.

В гостевых системах Linux модули ядра qxl и bochs_drm должны быть загружены для достижения достойной производительности.

SPICE

The SPICE project aims to provide a complete open source solution for remote access to virtual machines in a seamless way.

SPICE can only be used when using QXL as the graphical output.

The following is example of booting with SPICE as the remote desktop protocol, including the support for copy and paste from host:

From the SPICE page on the KVM wiki: «The -device virtio-serial-pci option adds the virtio-serial device, -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 opens a port for spice vdagent in that device and -chardev spicevmc, > adds a spicevmc chardev for that port. It is important that the chardev= option of the virtserialport device matches the > option given to the chardev option ( spicechannel0 in this example). It is also important that the port name is com.redhat.spice.0 , because that is the namespace where vdagent is looking for in the guest. And finally, specify name=vdagent so that spice knows what this channel is for.«

Connect to the guest by using a SPICE client. virt-viewer is the recommended SPICE client by the protocol developers:

The reference and test implementation spice-gtk can also be used:

Other clients, including for other platforms, are also available.

Using Unix sockets instead of TCP ports does not involve using network stack on the host system, so it is reportedly better for performance. Example:

For improved support for multiple monitors, clipboard sharing, etc. the following packages should be installed on the guest:

  • spice-vdagent : Spice agent xorg client that enables copy and paste between client and X-session and more. Enable spice-vdagentd.service after installation.
  • xf86-video-qxl : Xorg X11 qxl v >Password authentication with SPICE

If you want to enable password authentication with SPICE you need to remove disable-ticketing from the -spice argument and instead add password=yourpassword . For example:

Your SPICE client should now ask for the password to be able to connect to the SPICE server.

TLS encryption

You can also configure TLS encryption for communicating with the SPICE server. First, you need to have a directory which contains the following files (the names must be exactly as indicated):

  • ca-cert.pem : the CA master certificate.
  • server-cert.pem : the server certificate signed with ca-cert.pem .
  • server-key.pem : the server private key.

An example of generation of self-signed certificates with your own generated CA for your server is shown in the Spice User Manual.

Afterwards, you can run QEMU with SPICE as explained above but using the following -spice argument: -spice tls-port=5901,password=yourpassword,x509-dir=/path/to/pki_certs , where /path/to/pki_certs is the directory path that contains the three needed files shown earlier.

It is now possible to connect to the server using virt-viewer :

Keep in mind that the —spice-host-subject parameter needs to be set according to your server-cert.pem subject. You also need to copy ca-cert.pem to every client to verify the server certificate.

The equivalent spice-gtk command is:

vmware

Хотя он немного глючит, он работает лучше, чем std и cirrus. Установите драйверы VMware xf86-video-vmware и xf86-input-vmmouse для гостевых ОС Arch Linux.

virtio

virtio-vga / virtio-gpu is a paravirtual 3D graphics driver based on virgl. Currently a work in progress, supporting only very recent (>= 4.4) Linux guests with mesa (>=11.2) compiled with the option —with-gallium-drivers=virgl .

To enable 3D acceleration on the guest system select this vga with -vga virtio and enable the opengl context in the display device with -display sdl,gl=on or -display gtk,gl=on for the sdl and gtk display output respectively. Successful configuration can be confirmed looking at the kernel log in the guest:

As of September 2016, support for the spice protocol is under development and can be tested installing the development release of spice (>= 0.13.2) and recompiling qemu.

For more information visit kraxel’s blog.

cirrus

Графический адаптер цирруса был по умолчанию before 2.2. Его не следует использовать в современных системах.

Это как ПК, у которого вообще нет VGA карты. Вы даже не сможете получить к нему доступ с помощью опции -vnc . Кроме того, это отличается от опции -nographic , которая позволяет QEMU эмулировать карту VGA, но отключает отображение SDL.

Given that you used the -nographic option, you can add the -vnc display option to have QEMU listen on display and redirect the VGA display to the VNC session. There is an example of this in the #Starting QEMU virtual machines on boot section’s example configs.

When using VNC, you might experience keyboard problems described (in gory details) here. The solution is not to use the -k option on QEMU, and to use gvncviewer from gtk-vnc . See also this message posted on libvirt’s mailing list.

Audio

Драйвер аудио, используемый QEMU, устанавливается с помощью переменной среды QEMU_AUDIO_DRV :

Выполните следующую команду, чтобы получить параметры конфигурации QEMU, связанные с PulseAudio:

Перечисленные параметры можно экспортировать как переменные среды, например:

Guest

To get list of the supported emulation audio drivers:

To use e.g. hda driver for the guest use the -soundhw hda command with QEMU.

Installing virtio drivers

QEMU offers guests the ability to use paravirtualized block and network devices using the virtio drivers, which provide better performance and lower overhead.

  • A virtio block device requires the option -drive for passing a disk image, with parameter if=virtio :
  • Almost the same goes for the network:

Preparing an (Arch) Linux guest

To use virtio devices after an Arch Linux guest has been installed, the following modules must be loaded in the guest: virtio , virtio_pci , virtio_blk , virtio_net , and virtio_ring . For 32-bit guests, the specific «virtio» module is not necessary.

If you want to boot from a virtio disk, the initial ramdisk must contain the necessary modules. By default, this is handled by mkinitcpio’s autodetect hook. Otherwise use the MODULES array in /etc/mkinitcpio.conf to include the necessary modules and rebuild the initial ramdisk.

Virtio disks are recognized with the prefix v (e.g. vda , vdb , etc.); therefore, changes must be made in at least /etc/fstab and /boot/grub/grub.cfg when booting from a virtio disk.

Further information on paravirtualization with KVM can be found here.

You might also want to install qemu-guest-agent to implement support for QMP commands that will enhance the hypervisor management capabilities. After installing the package you can enable and start the qemu-ga.service .

Preparing a Windows guest

Block device drivers

New Install of Windows

Windows does not come with the virtio drivers. Therefore, you will need to load them during installation. There are basically two ways to do this: via Floppy Disk or via ISO files. Both images can be downloaded from the Fedora repository.

The floppy disk option is difficult because you will need to press F6 (Shift-F6 on newer Windows) at the very beginning of powering on the QEMU. This is difficult since you need time to connect your VNC console window. You can attempt to add a delay to the boot sequence. See qemu(1) for more details about applying a delay at boot.

The ISO option to load drivers is the preferred way, but it is available only on Windows Vista and Windows Server 2008 and later. The procedure is to load the image with virtio drivers in an additional cdrom device along with the primary disk device and Windows installer:

During the installation, the Windows installer will ask you for your Product key and perform some additional checks. When it gets to the «Where do you want to install Windows?» screen, it will give a warning that no disks are found. Follow the example instructions below (based on Windows Server 2012 R2 with Update).

  • Select the option Load Drivers .
  • Uncheck the box for «Hide drivers that aren’t compatible with this computer’s hardware».
  • Click the Browse button and open the CDROM for the virtio iso, usually named «virtio-win-XX».
  • Now browse to E:\viostor\[your-os]\amd64 , select it, and press OK.
  • Click Next

You should now see your virtio disk(s) listed here, ready to be selected, formatted and installed to.

Change Existing Windows VM to use virtio

Modifying an existing Windows guest for booting from virtio disk is a bit tricky.

You can download the virtio disk driver from the Fedora repository.

Now you need to create a new disk image, which will force Windows to search for the driver. For example:

Run the original Windows guest (with the boot disk still in IDE mode) with the fake disk (in virtio mode) and a CD-ROM with the driver.

Windows will detect the fake disk and try to find a driver for it. If it fails, go to the Device Manager, locate the SCSI drive with an exclamation mark icon (should be open), click Update driver and select the virtual CD-ROM. Do not forget to select the checkbox which says to search for directories recursively.

When the installation is successful, you can turn off the virtual machine and launch it again, now with the boot disk attached in virtio mode:

Network drivers

Installing virtio network drivers is a bit easier, simply add the -net argument as explained above.

Windows will detect the network adapter and try to find a driver for it. If it fails, go to the Device Manager, locate the network adapter with an exclamation mark icon (should be open), click Update driver and select the virtual CD-ROM. Do not forget to select the checkbox which says to search for directories recursively.

Balloon driver

If you want to track you guest memory state (for example via virsh command dommemstat ) or change guest’s memory size in runtime (you still won’t be able to change memory size, but can limit memory usage via inflating balloon driver) you will need to install guest balloon driver.

For this you will need to go to Device Manager, locate PCI standard RAM Controller in System devices (or unrecognized PCI controller from Other devices) and choose Update driver. In opened window you will need to choose Browse my computer. and select the CD-ROM (and don’t forget the Include subdirectories checkbox). Reboot after installation. This will install the driver and you will be able to inflate the balloon (for example via hmp command balloon memory_size , which will cause balloon to take as much memory as possible in order to shrink the guest’s available memory size to memory_size). However, you still won’t be able to track guest memory state. In order to do this you will need to install Balloon service properly. For that open command line as administrator, go to the CD-ROM, Balloon directory and deeper, depending on your system and architecture. Once you are in amd64 (x86) directory, run blnsrv.exe -i which will do the installation. After that virsh command dommemstat should be outputting all supported values.

Preparing a FreeBSD guest

Install the emulators/virtio-kmod port if you are using FreeBSD 8.3 or later up until 10.0-CURRENT where they are included into the kernel. After installation, add the following to your /boot/loader.conf file:

Then modify your /etc/fstab by doing the following:

And verify that /etc/fstab is consistent. If anything goes wrong, just boot into a rescue CD and copy /etc/fstab.bak back to /etc/fstab .

QEMU Monitor

While QEMU is running, a monitor console is provided in order to provide several ways to interact with the virtual machine running. The QEMU Monitor offers interesting capabilities such as obtaining information about the current virtual machine, hotplugging devices, creating snapshots of the current state of the virtual machine, etc. To see the list of all commands, run help or ? in the QEMU monitor console or review the relevant section of the official QEMU documentation.

Accessing the monitor console

When using the std default graphics option, one can access the QEMU Monitor by pressing Ctrl+Alt+2 or by clicking View > compatmonitor0 in the QEMU window. To return to the virtual machine graphical view either press Ctrl+Alt+1 or click View > VGA.

However, the standard method of accessing the monitor is not always convenient and does not work in all graphic outputs QEMU supports. Alternative options of accessing the monitor are described below:

  • telnet: Run QEMU with the -monitor telnet:127.0.0.1:port,server,nowait parameter. When the virtual machine is started you will be able to access the monitor via telnet:
  • UNIX socket: Run QEMU with the -monitor unix:socketfile,server,nowait parameter. Then you can connect with either socat or openbsd-netcat .

For example, if QEMU is run via:

It is possible to connect to the monitor with:

  • TCP: You can expose the monitor over TCP with the argument -monitor tcp:127.0.0.1:port,server,nowait . Then connect with netcat, either openbsd-netcat or gnu-netcat by running:
  • Standard I/O: It is possible to access the monitor automatically from the same terminal QEMU is being run by running it with the argument -monitor stdio .

Sending keyboard presses to the virtual machine using the monitor console

Some combinations of keys may be difficult to perform on virtual machines due to the host intercepting them instead in some configurations (a notable example is the Ctrl+Alt+F* key combinations, which change the active tty). To avoid this problem, the problematic combination of keys may be sent via the monitor console instead. Switch to the monitor and use the sendkey command to forward the necessary keypresses to the virtual machine. For example:

Creating and managing snapshots via the monitor console

It is sometimes desirable to save the current state of a virtual machine and having the possibility of reverting the state of the virtual machine to that of a previously saved snapshot at any time. The QEMU monitor console provides the user with the necessary utilities to create snapshots, manage them, and revert the machine state to a saved snapshot.

  • Use savevm name in order to create a snapshot with the tag name.
  • Use loadvm name to revert the virtual machine to the state of the snapshot name.
  • Use delvm name to delete the snapshot tagged as name.
  • Use info snapshots to see a list of saved snapshots. Snapshots are >Running the virtual machine in immutable mode

It is possible to run a virtual machine in a frozen state so that all changes will be discarded when the virtual machine is powered off just by running QEMU with the -snapshot parameter. When the disk image is written by the guest, changes will be saved in a temporary file in /tmp and will be discarded when QEMU halts.

However, if a machine is running in frozen mode it is still possible to save the changes to the disk image if it is afterwards desired by using the monitor console and running the following command:

If snapshots are created when running in frozen mode they will be discarded as soon as QEMU is exited unless changes are explicitly commited to disk, as well.

Pause and power options via the monitor console

Some operations of a physical machine can be emulated by QEMU using some monitor commands:

  • system_powerdown will send an ACPI shutdown request to the virtual machine. This effect is similar to the power button in a physical machine.
  • system_reset will reset the virtual machine similarly to a reset button in a physical machine. This operation can cause data loss and file system corruption since the virtual machine is not cleanly restarted.
  • stop will pause the virtual machine.
  • cont will resume a virtual machine previously paused.

Taking screenshots of the virtual machine

Screenshots of the virtual machine graphic display can be obtained in the PPM format by running the following command in the monitor console:

Tips and tricks

Starting QEMU virtual machines on boot

With libvirt

If a virtual machine is set up with libvirt, it can be configured with virsh autostart or through the virt-manager GUI to start at host boot by going to the Boot Options for the virtual machine and selecting «Start virtual machine on host boot up».

Пользовательский скрипт

Для запуска виртуальных машин QEMU при загрузке вы можете использовать следующий системный модуль и конфигурацию.

Then create per-VM configuration files, named /etc/conf.d/qemu.d/vm_name , with the following variables set:

type QEMU binary to call. If specified, will be prepended with /usr/bin/qemu- and that binary will be used to start the VM. I.e. you can boot e.g. qemu-system-arm images with type=»system-arm» . args QEMU command line to start with. Will always be prepended with -name $ -nographic . haltcmd Command to shut down a VM safely. In this example, the QEMU monitor is exposed via telnet using -monitor telnet. and the VMs are powered off via ACPI by sending system_powerdown to monitor with the nc command. You can use SSH or some other ways as well.

To set which virtual machines will start on boot-up, enable the qemu@vm_name.service systemd unit.

Mouse integration

To prevent the mouse from being grabbed when clicking on the guest operating system’s window, add the options -usb -device usb-tablet . This means QEMU is able to report the mouse position without having to grab the mouse. This also overrides PS/2 mouse emulation when activated. For example:

If that does not work, try the tip at #Mouse cursor is jittery or erratic.

Pass-through host USB device

To access physical USB device connected to host from VM, you can use the option: -usbdevice host:vendor_id:product_id .

You can find vendor_id and product_id of your device with lsusb command.

Since the default I440FX chipset emulated by qemu feature a single UHCI controller (USB 1), the -usbdevice option will try to attach your physical device to it. In some cases this may cause issues with newer devices. A possible solution is to emulate the ICH9 chipset, which offer an EHCI controller supporting up to 12 devices, using the option -machine type=q35 .

A less invasive solution is to emulate an EHCI (USB 2) or XHCI (USB 3) controller with the option -device usb-ehci, > or -device nec-usb-xhci, > respectively and then attach your physical device to it with the option -device usb-host. as follows:

You can also add the . port= setting to the previous option to specify in which physical port of the virtual controller you want to attach your device, useful in the case you want to add multiple usb devices to the VM.

USB redirection with SPICE

When using #SPICE it is possible to redirect USB devices from the client to the virtual machine without needing to specify them in the QEMU command. It is possible to configure the number of USB slots available for redirected devices (the number of slots will determine the maximum number of devices which can be redirected simultaneously). The main advantages of using SPICE for redirection compared to the previously-mentioned -usbdevice method is the possibility of hot-swapping USB devices after the virtual machine has started, without needing to halt it in order to remove USB devices from the redirection or adding new ones. This method of USB redirection also allows us to redirect USB devices over the network, from the client to the server. In summary, it is the most flexible method of using USB devices in a QEMU virtual machine.

We need to add one EHCI/UHCI controller per available USB redirection slot desired as well as one SPICE redirection channel per slot. For example, adding the following arguments to the QEMU command you use for starting the virtual machine in SPICE mode will start the virtual machine with three available USB slots for redirection:

Both spicy from spice-gtk (Input > Select USB Devices for redirection) and remote-viewer from virt-viewer (File > USB device selection) support this feature. Please make sure that you have installed the necessary SPICE Guest Tools on the virtual machine for this functionality to work as expected (see the #SPICE section for more information).

Enabling KSM

Kernel Samepage Merging (KSM) is a feature of the Linux kernel that allows for an application to register with the kernel to have its pages merged with other processes that also register to have their pages merged. The KSM mechanism allows for guest virtual machines to share pages with each other. In an environment where many of the guest operating systems are similar, this can result in significant memory savings.

If KSM is running, and there are pages to be merged (i.e. at least two similar VMs are running), then /sys/kernel/mm/ksm/pages_shared should be non-zero. See https://www.kernel.org/doc/Documentation/vm/ksm.txt for more information.

Multi-monitor support

The Linux QXL driver supports four heads (virtual screens) by default. This can be changed via the qxl.heads=N kernel parameter.

The default VGA memory size for QXL devices is 16M (VRAM size is 64M). This is not sufficient if you would like to enable two 1920×1200 monitors since that requires 2 × 1920 × 4 (color depth) × 1200 = 17.6 MiB VGA memory. This can be changed by replacing -vga qxl by -vga none -device qxl-vga,vgamem_mb=32 . If you ever increase vgamem_mb beyond 64M, then you also have to increase the vram_size_mb option.

Copy and paste

To have copy and paste between the host and the guest you need to enable the spice agent communication channel. It requires to add a virtio-serial device to the guest, and open a port for the spice vdagent. It is also required to install the spice vdagent in guest ( spice-vdagent for Arch guests, Windows guest tools for Windows guests). Make sure the agent is running (and for future, started automatically). See #SPICE for the necessary procedure to use QEMU with the SPICE protocol.

Windows-specific notes

QEMU can run any version of Windows from Windows 95 through Windows 10.

It is possible to run Windows PE in QEMU.

Fast startup

For Windows 8 (or later) guests it is better to disable «Turn on fast startup (recommended)» from the Power Options of the Control Panel as explained in the following forum page, as it causes the guest to hang during every other boot.

Fast Startup may also need to be disabled for changes to the -smp option to be properly applied.

Remote Desktop Protocol

If you use a MS Windows guest, you might want to use RDP to connect to your guest VM. If you are using a VLAN or are not in the same network as the guest, use:

Then connect with either rdesktop or freerdp to the guest. For example:

Troubleshooting

Virtual machine runs too slowly

There are a number of techniques that you can use to improve the performance of your virtual machine. For example:

  • Use the -cpu host option to make QEMU emulate the host’s exact CPU. If you do not do this, it may be trying to emulate a more generic CPU.
  • Especially for Windows guests, enable Hyper-V enlightenments: -cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time .
  • If the host machine has multiple CPUs, assign the guest more CPUs using the -smp option.
  • Make sure you have assigned the virtual machine enough memory. By default, QEMU only assigns 128 MiB of memory to each virtual machine. Use the -m option to assign more memory. For example, -m 1024 runs a virtual machine with 1024 MiB of memory.
  • Use KVM if possible: add -machine type=pc,accel=kvm to the QEMU start command you use.
  • If supported by drivers in the guest operating system, use virtio for network and/or block devices. For example:
  • Use TAP devices instead of user-mode networking. See #Tap networking with QEMU.
  • If the guest OS is doing heavy writing to its disk, you may benefit from certain mount options on the host’s file system. For example, you can mount an ext4 file system with the option barrier=0 . You should read the documentation for any options that you change because sometimes performance-enhancing options for file systems come at the cost of data integrity.
  • If you have a raw disk image, you may want to disable the cache:
  • Use the native Linux AIO:
  • If you use a qcow2 disk image, I/O performance can be improved cons >—device virtio-balloon .
  • It is possible to use a emulation layer for an ICH-9 AHCI controller (although it may be unstable). The AHCI emulation supports NCQ, so multiple read or write requests can be outstanding at the same time:

Mouse cursor is jittery or erratic

If the cursor jumps around the screen uncontrollably, entering this on the terminal before starting QEMU might help:

If this helps, you can add this to your

No visible Cursor

Add -show-cursor to QEMU’s options to see a mouse cursor.

If that still does not work, make sure you have set your display device appropriately.

Unable to move/attach Cursor

Replace -usbdevice tablet with -usb as QEMU option.

Keyboard seems broken or the arrow keys do not work

Should you find that some of your keys do not work or «press» the wrong key (in particular, the arrow keys), you likely need to specify your keyboard layout as an option. The keyboard layouts can be found in /usr/share/qemu/keymaps .

Guest display stretches on window resize

To restore default window size, press Ctrl+Alt+u .

ioctl(KVM_CREATE_VM) failed: 16 Device or resource busy

If an error message like this is printed when starting QEMU with -enable-kvm option:

that means another hypervisor is currently running. It is not recommended or possible to run several hypervisors in parallel.

libgfapi error message

The error message displayed at startup:

Install glusterfs or ignore the error message as GlusterFS is a optional dependency.

Kernel panic on LIVE-environments

If you start a live-environment (or better: booting a system) you may encounter this:

or some other boot hindering process (e.g. cannot unpack initramfs, cant start service foo). Try starting the VM with the -m VALUE switch and an appropriate amount of RAM, if the ram is to low you will probably encounter similar issues as above/without the memory-switch.

Windows 7 guest suffers low-quality sound

Using the hda audio driver for Windows 7 guest may result in low-quality sound. Changing the audio driver to ac97 by passing the -soundhw ac97 arguments to QEMU and installing the AC97 driver from Realtek AC’97 Audio Codecs in the guest may solve the problem. See Red Hat Bugzilla – Bug 1176761 for more information.

Could not access KVM kernel module: Permission denied

If you encounter the following error:

Systemd 234 assign it a dynamic id to group kvm (see bug). A workground for avoid this error, you need edit the file /etc/libvirt/qemu.conf and change the line:

«System Thread Exception Not Handled» when booting a Windows VM

Windows 8 or Windows 10 guests may raise a generic compatibility exception at boot, namely «System Thread Exception Not Handled», which tends to be caused by legacy drivers acting strangely on real machines. On KVM machines this issue can generally be solved by setting the CPU model to core2duo .

Certain Windows games/applications crashing/causing a bluescreen

Occasionally, applications running in the VM may crash unexpectedly, whereas they’d run normally on a physical machine. If, while running dmesg -wH , you encounter an error mentioning MSR , the reason for those crashes is that KVM injects a General protection fault (GPF) when the guest tries to access unsupported Model-specific registers (MSRs) — this often results in guest applications/OS crashing. A number of those issues can be solved by passing the ignore_msrs=1 option to the KVM module, which will ignore unimplemented MSRs.

источник

Читайте также:  Установка ветровая для выработки энергии

Добавить комментарий

Adblock
detector