rPman

С вероятностью 99.(9)% облачные сервисы, позволяющие запускать приложения android не предоставляют возможности отладки.

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

При наличии хорошего канала (либо сервер прямо в твоем городе) можно так работать почти без лагов, я рекомендую linux машину с x2go сервером (клиенты есть по до все) это очень дешево (но не будет поддержки видеоускорителя ни в каком виде, но тут с эмулятором android и так проблемы)

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

Причина - нет адекватной поддержки проброса устройств, чаще всего она ограничена либо работает только при опредленных условиях и по разному на разных устройствах (в смысле компьютер), зависит от производителя процессора intel/amd, возможностей материнки и кучи других мелких нюансов (например десктопные материнки чаще всего ограничивают функционал в биосе). С момента активного использованиея EFI биосов, это еще сильнее усложнилось.

* Итак - проброс всего pci(-e) устройства вместе с контроллерами и соответственно устройствами, через него подключаемыми. Это самый удобный с точки зрения использования способ (потому как после запуска виртуальной машины контроллер уже доступен внутри и чаще всего без дополнительных движений видит устройство 'как родное'.

В linux мне известно что это поддерживает только qemu/kvm и поддержка требует соответствующие аппаратные возможности (IOMMU/VT-d плюс в принципе аппаратная виртуализация), даже некоторые gpu могут быть так проброшены внутрь виртуалки, производители видеокарт об этом знают и старательно ставят палки в колеса, так как такой функционал они хотят чтобы пользователи использовали только с их 10х дороже серверными вариантами видеокарт). Требует хорошего прогружения в настройки linux, хотя бы чтобы исключить инициализацию устройство самим linux (некоторые устройства не любят включаться два раза подряд без железной перезагрузки).

* Промежуточный вариант - проброс USB устройств. Это установка в гостевой операционной системе специального драйвера USB который по сети или каким-либо другим способом (например virtualbox usb при установке проприетарного guest additions) транслирует весь трафик, включая управляющий с хост машины для выбранного usb устройства или контроллера. Точно помню отдельные приложения для трансляции usb по сети между машинами даже без виртуализации, но лично сам не пользовался, гуглите решения обычно платные.

* Проброс 'блочного устройства' (читай дисков или отдельных разделов, и даже файлов), в этом случае гостевая ос не имеет доступа к самому устройству, но только к данным на нем. Формально это просто подключение диска из файла (потому как даже в windows диск и раздел это буквально файл, который можно открыть fopen по специальному имени). Разные системы виртуализации дают разный интерфейс и удобство. qemu с тем же libvirt - удобнее чем к примеру virtualbox (там нужно в консоли специальную 'скрытую' команду использовать)

p.s. Проброс видеоускорителя - есть еще протоколы spice но на сколько я знаю они не достаточно функциональны
Ну и проброс всякой мелочовки типа клавиатура, мышь, планшет/сенсорный экран, мониторы. Это все виртуальные сущности, реальное железо тут не пробрасывается.

p.p.s. драйвера windows для гостевых систем с каждым разом становятся все хуже и хуже, если я верно понял палки в колеса вставляет сама майкрософт, например windows 10 адекватно в virtualbox уже не работает gpu без глюков (я обхожу большинство проблем только с помощью rdp подключения)

В настройках сетевого устройства VirtualBox выбери тип сети - сетевой мост (bridge) и выбери сетевое устройство хоста, которое подключено к провайдеру (там где стоит dhcp сервер, раздающий нужный тебе ip)

там же настраивается mac адрес, так как провайдер выдает ip адреса соответственно этому mac.

В настройках сетевых устройств сменить тип NAT на Сетевой мост, в этом случае машина будет получать ip адрес по тем же правилам что и любая другая машина в твоей сети

Виртуализация не позволяет объединять мощности!

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

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

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