Виртуализация ARM‑архитектуры: запуск QEMU/KVM‑based виртуальных машин и эмуляция x86‑ядра в Termux

Termux — удобная среда для работы в Linux-подобном пользовательском пространстве на Android. Когда устройство построено на ARM‑архитектуре, возникает естественный интерес: можно ли запускать виртуальные машины и тестировать программное окружение, рассчитанное на другую архитектуру, например на x86, а также ускорять работу за счет аппаратной виртуализации (KVM) там, где это поддерживается.

Практический ответ: в Termux обычно доступны сценарии с эмуляцией (QEMU) и, в ряде случаев, ускорение через KVM. При этом набор возможностей зависит от конкретного устройства, версии Android, прав и настроек ядра (особенно для KVM). Важно также понимать разницу между «виртуальной машиной» и «эмуляцией ядра»: эмуляция x86‑ядра — это не то же самое, что запуск x86‑VM «как есть», но может быть полезна для исследований, отладки и изучения загрузочных сценариев.

О юридической и практической стороне вопроса

Следуйте правилам локального законодательства РФ и корпоративной политики, не используйте материалы и образы, на которые у вас нет прав. Технически допустимо использовать публичные/лицензионные образы ОС для тестирования, а также изучать механизмы виртуализации в образовательных целях.

Отдельно отметим: тема VPN в этом материале затрагивается только в контексте создания локальной сети внутри вашего стенда и никак не для обхода блокировок.

Что вам понадобится

Android‑устройство на ARM.
Termux (желательно последней версии).
Достаточно места на диске под образы (виртуальные диски, initramfs, ISO и т.п.).
Проверка наличия KVM: на части устройств KVM будет недоступен без специальных условий.
Умение работать с командной строкой и базовые навыки Linux.

Подготовка Termux: обновление окружения и базовые пакеты

Начните с обновления пакетов и установки инструментов. Ниже приведен типовой набор.

pkg update && pkg upgrade -y
pkg install -y proot-distro wget curl ca-certificates gnupg coreutils util-linux tar xz-utils nano

Для QEMU и эмуляции иногда требуется больше зависимостей. В зависимости от того, как вы будете устанавливать QEMU (через репозитории Termux, через сборку или через внешние источники), набор пакетов может отличаться. Ниже — общая логика подготовки.

Проверка аппаратной виртуализации (KVM)

KVM в Android доступен только если ядро устройства и настройки позволяют использовать KVM для пользовательского пространства. В Termux напрямую «включить» KVM нельзя: это свойство системы. Зато можно проверить, есть ли доступ.

Попробуйте проверить наличие устройств виртуализации:

ls -l /dev/kvm 2>/dev/null || echo "KVM device (/dev/kvm) недоступен"

Если /dev/kvm недоступен, у вас, скорее всего, останется только режим чистой эмуляции (без ускорения). Если доступ есть, дальнейшие шаги зависят от того, разрешен ли запуск QEMU с KVM в вашем контексте.

Также проверьте, доступен ли модуль (это не всегда возможно в Android без расширенных прав):

dmesg | grep -i -E "kvm|kvm-arm" | tail -n 20

Если команды не работают из-за ограничений, не пытайтесь «ломать» систему — это зависит от устройства. Для практической работы достаточно тестов запуска QEMU.

Установка QEMU в Termux: общий подход

В Termux QEMU может быть доступен в зависимости от текущих репозиториев и архитектурных сборок. На практике есть два пути: установить готовый пакет или подготовить окружение для работы QEMU (включая зависимости). Рассмотрим установку через пакетный менеджер, если QEMU доступен.

pkg install -y qemu-system-x86_64 qemu-utils

Если пакет не находится, вам потребуется уточнить доступные пакеты через поиск:

pkg search qemu

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

Концепция сценариев: эмуляция x86‑ядра vs виртуальная машина x86

При работе с x86 в ARM‑среде есть две близкие, но разные задачи:

Эмуляция x86‑ядра: вы запускаете x86‑ядро Linux внутри виртуальной среды QEMU, часто с initrd, командной строкой ядра и подходящим виртуальным BIOS/UEFI или без загрузчика — в зависимости от сценария.
Запуск виртуальной машины: вы создаете VM с виртуальным железом, подсовываете образ диска (например qcow2) и запускаете гостевую ОС целиком.

В обоих случаях центральный компонент — QEMU. Разница в том, что для «x86‑ядра» вам важнее подготовить initrd и корректные параметры загрузки, а для «VM» — обеспечить загрузочный носитель и драйверы/железо.

Запуск x86‑ядра через QEMU в ARM‑окружении

Ниже приведен концептуальный пример. Он предполагает, что у вас есть:

x86‑kernel (например, bzImage или vmlinuz с архитектурой x86_64 или i386 — зависит от режима),
initrd,
минимальная командная строка ядра.

Убедитесь, что выбранные артефакты соответствуют друг другу и архитектуре, иначе загрузка не состоится.

Создайте рабочую директорию:

mkdir -p ~/vm-x86/kernel ~/vm-x86/initrd ~/vm-x86/root
cd ~/vm-x86

Далее положите в kernel/ и initrd/ ваши файлы (названия замените на ваши фактические).

Пример команды QEMU для x86_64 (без претензии на «универсальную» совместимость — параметры и устройство могут отличаться в зависимости от ядра):

qemu-system-x86_64 
  -m 1024 
  -smp 2 
  -nographic 
  -kernel ./kernel/vmlinuz 
  -initrd ./initrd/initrd.img 
  -append "console=ttyS0 root=/dev/ram rdinit=/linuxrc rw" 
  -no-reboot

Если вы используете не root=/dev/ram, а другую схему (например, initrd содержит корневую ФС), подстройте -append под ваш initrd и ожидаемую точку монтирования. Для удобства диагностики всегда смотрите вывод консоли: режим -nographic направляет вывод в терминал.

Запуск виртуальной машины x86_64 на QEMU (с диском)

Для VM нужен виртуальный накопитель. Часто используют qcow2. Пример последовательности:

mkdir -p ~/vm-x86/disk
cd ~/vm-x86

qemu-img create -f qcow2 disk/system.qcow2 20G

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

Пример запуска установки (идея):

qemu-system-x86_64 
  -m 2048 
  -smp 2 
  -hda ./disk/system.qcow2 
  -cdrom ./iso/installer.iso 
  -boot d 
  -nographic 
  -no-reboot

После установки перезапустите VM уже с загрузкой с диска:

qemu-system-x86_64 
  -m 2048 
  -smp 2 
  -hda ./disk/system.qcow2 
  -boot c 
  -nographic 
  -no-reboot

Если установка/загрузка не идет, проверьте совместимость гостевой ОС с виртуальным «железом» (модель CPU/чипсет/сетевые устройства). Иногда помогает указание более конкретных параметров QEMU.

Использование KVM (если доступно) для ускорения

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

Попробуйте базовый сценарий запуска VM с KVM:

qemu-system-x86_64 
  -enable-kvm 
  -m 2048 
  -smp 2 
  -hda ./disk/system.qcow2 
  -nographic

Если -enable-kvm не работает, QEMU обычно выдаст ошибку. В этом случае вы продолжаете в режиме чистой эмуляции, удалив -enable-kvm и снова запускаете.

Важно: ускорение не гарантировано, и в некоторых случаях даже при наличии /dev/kvm могут быть ограничения прав/контекста.

Сеть в QEMU: локальная лабораторная схема (без обхода блокировок)

Для тестирования удобно поднимать локальную сеть, чтобы гостевая ОС имела связность с вашим хостом (Termux‑окружением) и с другими контейнерами/сервисами в рамках вашей локальной машины.

Один из типовых подходов — пользовательская сеть (slirp) или TAP/bridge. В Android часто проще user-networking.

Пример запуска с простым NAT-сетевым интерфейсом (идея):

qemu-system-x86_64 
  -m 2048 
  -smp 2 
  -hda ./disk/system.qcow2 
  -nographic 
  -netdev user,id=net0,hostfwd=tcp::2222-:22 
  -device e1000,netdev=net0

В примере проброс hostfwd делает доступ к SSH гостя через порт 2222 на стороне хоста (Termux/устройство). Внутри гостевой ОС включите SSH и настройте сеть.

Это не «VPN для обхода блокировок», а обычная лабораторная схема сетевого доступа в рамках вашего стенда.

Производительность: как выжать максимум на ARM без KVM

Если KVM недоступен, эмуляция может быть медленной. Практические меры:

Сокращайте параметры: меньше RAM (-m) и меньше vCPU (-smp) для начала.
Используйте компактные образы дисков (или отдельные тестовые окружения).
Включайте режимы, уменьшающие графическую нагрузку: -nographic для серийной консоли.
Минимизируйте частые операции ввода-вывода: переноситесь к загрузочным сценариям через initrd и RAM-диски, если задача исследовательская.

Типовые проблемы и диагностика

Черный экран / нет консоли: проверьте console=ttyS0, используйте -nographic и подстройте -append под ваш initrd.
Ошибка KVM: запускайте без -enable-kvm, проверьте доступность /dev/kvm и лог QEMU.
ОС не загружается: убедитесь, что выбранные образы соответствуют целевой архитектуре (x86_64 vs i386) и что образ диска/ISO согласован с железом.
Проблемы с сетью: проверьте тип сетевого устройства (-device) и настройки гостевой ОС.

Заключение

Виртуализация ARM‑устройств в Termux через QEMU позволяет запускать виртуальные машины и проводить эксперименты с загрузкой x86‑ядра. Роль KVM — это потенциальное ускорение, но доступность зависит от конкретного устройства и конфигурации ядра: в большинстве «обычных» сценариев вы начнете с эмуляции и только затем проверите ускорение. С точки зрения инженерной дисциплины важно аккуратно подбирать архитектуру (x86_64/i386), правильно задавать параметры ядра при эмуляции и грамотно организовывать сетевую часть локального стенда.

Если вам нужна помощь с подбором конфигурации под ваше устройство, настройкой QEMU/KVM, подготовкой загрузочных сценариев или разбором ошибок запуска — обращайтесь в РыбинскЛАБ. Мы поможем организовать стенд, настроить окружение и довести эксперимент до результата.