Эмуляция ARM‑и x86‑платформ с QEMU в Termux: запуск виртуальных машин и кросс‑компиляция системных образов

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

отладки программ, ориентированных на ARM или x86;
разработки и тестирования инсталляционных/минимальных образов;
кросс‑компиляции компонентов и проверки сборок в изолированной среде;
изучения низкоуровневых сценариев (загрузка ядра, initramfs, сетевые режимы).

Важно различать режимы: QEMU может работать в режиме эмуляции (software emulation), где совместимость выше, а скорость ниже, и в режиме аппаратной виртуализации, где скорость выше, но доступность зависит от устройства и настроек (в Android это может требовать поддержки KVM и наличия соответствующих прав/модулей).

Подготовка Termux и базовые требования

Прежде чем собирать окружение, убедитесь, что у вас есть:

актуальная версия Termux;
достаточно места на диске (образы и rootfs легко занимают сотни мегабайт);
желательно — устройство с большим объёмом RAM, иначе многие гостевые системы будут работать медленно.

Далее обновите пакеты и установите зависимости. В качестве отправной точки используйте стандартный набор инструментов:

pkg update -y && pkg upgrade -y
pkg install -y proot-distro wget tar xz-utils git python clang make nano
autoconf automake libtool pkg-config

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

Установка QEMU в Termux

В Termux доступны разные подходы к установке QEMU:

через пакеты Termux (если версия присутствует в репозитории);
сборка QEMU из исходников (когда нужен конкретный вариант или конфигурация).

Рекомендуется начать с пакетного варианта:

pkg install -y qemu

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

Эмуляция ARM в QEMU: типовые сценарии

Для ARM в QEMU часто используют виртуальные машины типа virt (generic ARM board). Сценарий обычно строится вокруг загрузки:

ядра Linux (обычно Image);
initramfs или rootfs;
конфигурации загрузки (cmdline) и параметров консоли.

Возможны два практических подхода:

Запуск с rootfs в файловой системе (initramfs или статический rootfs), без полноценной инсталляции.
Загрузка образа диска (qcow2/raw) с установленной системой.

Ниже — общий шаблон для старта ARM‑эмуляции (конкретные имена файлов зависят от вашей заготовки ядра и rootfs):

# Примерный шаблон (адаптируйте под ваши файлы и архитектуру)
qemu-system-aarch64 \
  -M virt \
  -cpu cortex-a57 \
  -m 1024 \
  -smp 2 \
  -nographic \
  -kernel ./Image \
  -initrd ./initrd.img \
  -append "console=ttyAMA0 root=/dev/vda rw" \
  -drive if=virtio,file=./rootfs.qcow2,format=qcow2

Ключевые моменты:

-nographic переводит вывод в консоль (удобно для Termux);
раздел -append должен соответствовать вашему способу монтирования rootfs;
-drive и параметр -M virt задают совместимость виртуального железа.

Если вы работаете с ARMv7, используйте соответствующую команду QEMU (например, qemu-system-arm) и подбирайте нужные параметры машины.

Эмуляция x86 в QEMU: загрузка и удобные варианты

Для x86 обычно выбирают машинные параметры, близкие к PC‑совместимому окружению. Самый практичный вариант для обучения и отладки — запуск с дисковым образом, где уже есть загрузчик и разделы.

Общий шаблон для x86_64 с UEFI/BIOS зависит от вашей заготовки. Если вы используете готовый образ диска (qcow2/raw), команда будет выглядеть примерно так:

qemu-system-x86_64 \
  -m 2048 \
  -smp 2 \
  -nographic \
  -drive if=virtio,file=./vm_disk.qcow2,format=qcow2 \
  -netdev user,id=net0 \
  -device virtio-net-pci,netdev=net0

Когда вы эмулируете через software emulation, x86‑гости обычно запускаются заметно быстрее/стабильнее, чем ARM‑гости на слабых устройствах, но это зависит от конкретного CPU/ABI Android‑устройства.

Оптимизация производительности на Android

Тормоза в QEMU на мобильных устройствах — нормальное явление. Но вы можете заметно улучшить интерактивность и сократить ожидания:

Ставьте умеренные значения памяти и CPU: -m 512/1024/2048, -smp 1/2.
Используйте -nographic для удобной консоли в Termux.
Работайте с минимальными гостевыми системами (busybox/initramfs/легковесные rootfs).
Для файловых систем используйте qcow2, чтобы уменьшить размер образа и ускорить операции с диском.
Отключайте ненужные устройства (например, графику), чтобы снизить накладные расходы.

Пример компромиссной конфигурации для ускорения итераций:

qemu-system-x86_64 \
  -m 1024 -smp 1 \
  -nographic \
  -drive if=virtio,file=./vm_disk.qcow2,format=qcow2 \
  -device virtio-net-pci,netdev=net0 \
  -netdev user,id=net0,hostfwd=tcp::2222-:22

Последний параметр демонстрирует проброс порта для SSH в гостевой системе (удобно для тестов без графического интерфейса).

Сеть в гостях: варианты и практики

В Termux типичный вариант — user‑mode networking через -netdev user. Он не требует прав на уровне ядра, но имеет ограничения по “сложным” сценариям.

Шаблон:

-netdev user,id=net0 \
-device virtio-net-pci,netdev=net0

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

Кросс‑компиляция системных образов: архитектура и инструменты

Кросс‑компиляция в контексте Termux обычно решает две задачи:

собрать пользовательское пространство (утилиты, демоны, библиотеки) под нужную архитектуру;
собрать ядро/модули или userland, а затем упаковать результат в rootfs для QEMU‑запуска.

На практике часто используют один из подходов:

Сборка в отдельном Linux‑окружении (например, через proot-distro или контейнерные средства) с нужным toolchain.
Использование ready‑made toolchain (например, Linaro/Buildroot/Yocto/подобные системы) и сборка артефактов под ARM/x86.

Для демонстрации минимального шага — подготовьте инструменты и зависимости, а затем собирайте исходники с заданным target. Точная команда зависит от проекта (glibc/musl, BusyBox, утилиты, собственные сервисы).

Общий принцип: определите целевую архитектуру и ABI, затем используйте cross‑compiler, указав префикс. Пример шаблона (адаптируйте под ваш toolchain):

# Примерная схема (не универсальная, зависит от конкретного toolchain)
export TARGET=aarch64-linux-gnu
export CC=${TARGET}-gcc
export AR=${TARGET}-ar
export STRIP=${TARGET}-strip

./configure --host=$TARGET --prefix=/usr
make -j$(nproc)
make DESTDIR=./_install install

# Далее _install упаковывается в rootfs или copy в образ VM

После сборки формируйте rootfs: копируйте нужные файлы в структуру файловой системы, обеспечьте наличие init (или корректного загрузочного сценария) и библиотек. Затем упакуйте в образ, который сможет загрузить QEMU.

Сборка rootfs и создание образа диска для VM

Типовой workflow:

Создать директорию rootfs (например, rootfs/).
Скопировать туда собранные компоненты и базовую структуру (/dev, /proc при необходимости через init, /etc).
Сформировать дисковый образ (qcow2) нужного размера.
Разметить и смонтировать образ, перенести rootfs внутрь, затем размонтировать.

В Termux работа с loop‑устройствами и разметкой может зависеть от доступных прав. Если прямой подход недоступен, используйте заранее подготовленные инструкции под вашу модель устройства и возможности Android.

Пример “идеологического” шаблона (команды разметки/loop‑маппинга могут требовать донастройки в вашем окружении):

# Шаблон. Вам может потребоваться адаптация под доступные устройства в Android.
qemu-img create -f qcow2 vm_disk.qcow2 2G

# Далее: разметить/отформатировать и перенести rootfs.
# (Используйте проверенные процедуры, совместимые с вашим доступом к устройствам.)

После подготовки образа проверьте запуск в QEMU, подстройте kernel command line и убедитесь, что init и точки монтирования работают.

Практический чек-лист отладки

Если VM не стартует или гостевая система “висит”, обычно причины лежат в одном из блоков:

Несовпадение архитектуры (ARMv7 vs AArch64, x86_64 vs i386).
Неправильная машина QEMU (-M) или CPU‑модель.
Некорректные параметры загрузки (-append), особенно root device и console.
Отсутствие нужных драйверов (virtio‑blk, virtio‑net) в initramfs или в составе системы.
Проблемы с совместимостью формата образа (raw vs qcow2, наличие нужных разделов).

Для ARM часто самое полезное — внимательно смотреть консольный вывод через -nographic и корректно настроенный console=ttyAMA0 или аналог.

Заключение

Эмуляция ARM и x86 с QEMU в Termux — реальный практический способ запускать виртуальные машины, проверять сборки и организовывать кросс‑компиляцию системных компонентов в мобильной среде. Успех обычно зависит от правильного выбора параметров QEMU, совместимости образов и грамотной организации rootfs/дисковых файлов, а также от того, насколько “лёгкой” вы делаете гостевую систему под ресурсы Android.

Если вы хотите ускорить путь от идеи до рабочего стенда (подбор параметров эмуляции, подготовка образов, настройка кросс‑компиляции и отладочные сценарии), команда РыбинскЛАБ поможет с консультациями и внедрением решений под ваши задачи.