Android kvm что это

Настройка KVM для Android Emulator

ОС Debian Jessie Android эмулятор просит kvm. Погуглив, нашел статью https://wiki.debian.org/ru/KVM#A.2BBCMEQQRCBDAEPQQ.2BBDIEOgQw-. Установил пакеты qemu-kvm virt-manager. Тем не менее при выполнении :

Что нужно еще сделать, чтобы kvm заработал?

А ты уверен что он уже не работает? android-эмулятору насколько я понял не нужно ничего, кроме модуля ядра.

Как это проявляется?

Не работает, потому что не находит kvm-ok Вот что говорит Android Studio : скрин

Может быть компьютер не поддерживает аппаратную виртуализацию или она выключена в bios.

не хватает еще одного модуля, kvm_intel или kvm_amd

я думаю ему не хватает прав.

1. Поставить пакет qemu-kvm
2. Добавить kvm-intel или kvm-amd в зависимости от процессора
3. Опционально добавить еще и vhost_net в /etc/modules
4. Открыть для себя genymotion и плагин для Android Studio
5. Удалить эту ужасную Android Studio и поставить нормальную IDEA
6. Обойти регистрацию для получения образов с genymotion
Как-то так.

Источник

Добавление модуля в андроид KVM_intel

Стоит задача запустить ВМ с -enable-kvm на планшете c intel atom. На планшете стоит андроид в сhroot запущен debian . При попытке запуска qemu-system-x86_64 с опцией -enable-kvm выдает ошибку # Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory

#lsmod | grep «kvm» libkmod: ERROR ../libkmod/libkmod-module.c:1638 kmod_module_new_from_loaded: could not open /proc/modules: No such file or directory

#kvm-ok INFO: /dev/kvm does not exist HINT: sudo modprobe kvm_intel modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file ‘/lib/modules/3.4.34-cm-01361-g87c04bb/modules.dep.bin’

На сколько я понял необходимо добавить модуль в ядро kvm_intel(как это сделать ? откуда скачивать сам модуль ? ).Если есть другие варианты запуска ВМ с kvm предлагайте

Других вариантов запуска виртуальной машины с KVM нет. Но вы уверены что ваш процессор поддерживает расширение Intel VT-x? Без него KVM не заработает.

Ты уверен что планшетник умеет в виртуализацию? Можешь без kvm запускать если что, io тормозить будет из наиболее заметного. Я имею в виду, больше обычного.

Без KVM будут сильные тормоза

# egrep ‘(vmx|svm)’ —color=always /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf nonstop_tsc_s3 pni dtes64 monitor ds_cpl vmx est tm2 ssse3 xtpr pdcm movbe lahf_lm arat dtherm tpr_shadow vnmi flexpriority flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf nonstop_tsc_s3 pni dtes64 monitor ds_cpl vmx est tm2 ssse3 xtpr pdcm movbe lahf_lm arat dtherm tpr_shadow vnmi flexpriority flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf nonstop_tsc_s3 pni dtes64 monitor ds_cpl vmx est tm2 ssse3 xtpr pdcm movbe lahf_lm arat dtherm tpr_shadow vnmi flexpriority flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf nonstop_tsc_s3 pni dtes64 monitor ds_cpl vmx est tm2 ssse3 xtpr pdcm movbe lahf_lm arat dtherm tpr_shadow vnmi flexpriority

Виртуализация работает запускал оси но тормозит ужасно

uname -a в студию. Затем можешь поискать пакет с ядром этой же версии, распаковать модули и запустить их через insmod $modname.ko . Но лучше вовсе пересобрать ядро, уже включив нужные модули, мороки меньше будет.

Linux localhost 3.4.34-cm-01361-g87c04bb #1 SMP PREEMPT Sat Dec 10 16:08:35 UTC 2016 i686 GNU/Linux

Пересборка ядра как происходит ? step-by-step что нужно скачивать\делать?

Зависит от устройства. Поищи мануалы в интернете, как и исходники самого ядра (у тебя, так понимаю, CyanogenMod, исходники наверняка лежат там же, откуда ты скачал прошивку). Модель устройства прямым текстом не сказана, поэтому чёткую инструкцию предоставить не получится.

Linux localhost 3.4.34-cm-01361-g87c04bb #1 SMP PREEMPT Sat Dec 10 16:08:35 UTC 2016 i686 GNU/Linux

Цыганомод? Ну так исходники есть, собирай, чо.

Источник

VirtualBox — Запуск Android эмулятора в виртуальной среде для тестирования Android проекта

Введение

В данной статье я постараюсь описать пример инфраструктуры для автотестов Android приложений (mobile automation), а именно, среду для проведения тестранов UI автотестов на эмуляторе Android девайса в виртуальной среде.

Требования:

Для Android эмулятора нужна поддержка Intel Virtualization Technology или AMD Virtualization. Поэтому часто тестировщик сталкивается с необходимостью запуска тестранов только в нативной среде ПК с прямым доступом к центральному процессору.

В этом случае схема получается такая:

Трудности:

Невозможно легко пересоздать среду эмулятора.

Среда не создаётся перед проведением тестирования, и после проведения не удаляется, поэтому среда может влиять на тестируемое приложение.

Починка и настройка среды занимает много времени.

Предлагаемое решение в данной статье:

Создать VM с использованием возможностей nested virtualization VirtualBox (более подробное описание технологии в этой статье).

Пробросить поддержку Intel-VT или KVM внутрь созданной виртуальной машины.

Изнутри VM создать и запустить Android эмулятор девайса.

Провести тестран UI тестов приложения.

После проведения тестирования уничтожить VM.

В этом случае схема получится такая:

Предполагаемые преимущества:

VM можно автоматически создавать перед проведением тестирования, а после окончания уничтожать. В таком случае каждый новый тестран будет проведен в идеально чистых условиях.

Уменьшится время поддержки среды и управляющего ПО, так как не нужно каждый раз руками ничего устанавливать и чинить неисправности инвайронмента.

В настоящей статье будет использоваться оборудование:

процеcсор: Intel i5-1035G1

в BIOS включена поддержка виртуализации процессора

Шаг 1: Установка ПО на нативную OS

Отдельно обращу внимание на управление машиной. Будем использовать протокол VNC для создания удобного удаленного рабочего стола. Протокол универсальный, для Linux, Windows, Mac и т.д.

x11vnc сервер

Запуск с параметрами:

Установка VirtualBox

Вводим в командной строке:

Создание VM

Мы пойдем по самому простому пути и создадим VM из интерфейса VirtualBox с такими характеристиками. В дальнейшем создание VM будет code-first

Количество CPU — не больше половины имеющихся на Вашем процессоре (в идеале половина)

Оперативная память — будет достаточно 4Gb

Nested Virtualization можно также включить из командной строки:

Далее переходим в саму VM.

Шаг 2: Установка ПО на VM

В первый раз мы установим всё руками. В дальнейшем весь установочный сценарий будет помещен в Packer, что позволит нам создавать VM с нужными настройками каждый раз перед началом тестирования.

Устанавливаем последний образ Ubuntu с официального сайта.

Установка KVM

Установка Android command line tools

Проверяем, что sdkmanager работает и Android SDK доступен:

Устанавливаем Android tools

Устанавливаем Git и клонируем проект

В данном примере я использую пустой проект мобильного Android приложения. В нём уже есть дефолтный интеграционный тест. Нам этого будет вполне достаточно.

Шаг 3: Проведение тестирования проекта на созданном Android эмуляторе

ADB видит подключенный к нему эмулятор:

Ура! Тест пройден!

Негативный тест

Чтобы убедится, в том что именно позволило нам сбилдить тесты, мы сделаем один негативный тест и воспроизведем запуск эмулятора в обычной VM.

Переустановка VirtualBox на родительской машине (чтобы избежать ошибочное сохранение конфигов)

VM мы создаём без проброса виртуализации и с одним CPU:

В созданной VM мы не устанавливаем:

Остальные шаги аналогичны шагу №2 с установкой ПО. Попробуем еще раз наш тестран. Обратите внимание, что ADB также видит эмулятор:

Ура! Тест не пройден! Никогда еще так не радовался проваленному тестрану:

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

Заключение

Мы сделали первый этап построения инфраструктуры для проведения автотестов Android приложений. Следующим этапом должно стать упаковка описанного выше сценария в Packer (ссылка на официальный сайт) который умеет работать с образами VirtualBox. Затем весь сценарий мы попробуем запустить из CI Jenkins. Если учесть, что плагин для него уже порядком устарел, то будет очень интересно.

Все результаты опубликую, как пополнения к этой статье.

В идеале, у нас должна получится code-first инфраструктура для тестрана UI и интеграционных автотестов для Android приложений, которую можно поднять на любом современном офисном ПК, которая работает автономно, билдит тесты на родных Android эмуляторах и есть не просит.

Источник

Общие принципы работы 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 в качестве ответа на вопрос одного из участников канала.

Напишите в комментариях, в каких местах я не правильно понимаю тему или если есть, что дополнить.

Источник