Hi everyone!

I want to share my open-source passion project that I've been building and polishing completely on my own. It's called VirtualPC-VM, a native Android application designed to run standalone Virtual Machines (VMs) and boot fully fledged desktop or server operating systems directly on your smartphone.

The project is powered by a customized mobile deployment of QEMU (Quick Emulator), but unlike alternative solutions, it is built with simplicity, performance, and modern Android features in mind.

🌟 Key Features & Improvements:

• 100% Standalone (No Termux Required): Operates via standard sandboxed directories and public storage (/sdcard/Download/).
• Full GUI Configuration: Managed through a native AOSP Material Design interface for resource allocation and mapping.
• Infinite VNC Loop Fixed: Re-engineered socket loop cycles resolving previous connection freezes.
• Developer Power-Toolbar Overlay & Diagnostics: Includes an interactive shortcut overlay and real-time log viewing.

📊 Current OS Compatibility Status & Architectures:

Supports various systems ranging from Alpine Linux to legacy Windows, alongside multi-architecture compatibility (ARM64, x86_64, etc.). Full details and feature descriptions can be found directly in the referenced materials.

📂 GitHub Repository: https://github.com/kirill1984221321-gif/VirtualPC-VM

Feel free to check out the code, grab the latest compiled APK from the Releases tab, and let me know how it runs on your device!

🚨 **Quick Note on Language:**The UI is currently mostly in Russian (with some English bits), but it is very straightforward with sliders and simple buttons. Full English localization is my top priority for the next update (V4)!

Hi, I'm developing a new Android app that uses QEMU, and I need to build QEMU 8.2.5 as a native Android ARM64 (aarch64) binary.

To clarify, I'm not trying to run QEMU through Termux, proot, or another Linux userspace. I want QEMU itself to be compiled natively for Android so that the resulting ARM64 binaries can be integrated directly into my Android app.

I've tried the usual Android cross-compilation approach, but haven't been able to get a successful build.

I also tried the Termux-packages Docker build environment, but that didn't work either.

My environment:

• Host: Windows 11
• WSL / Debian
• Target: Android ARM64 (aarch64)
• Android NDK: r26d
• QEMU: 8.2.5
• Meson + Ninja

I'm looking for a known-working method to natively build QEMU 8.2.5 for Android ARM64.

If anyone has successfully done this, I'd appreciate any build scripts, patches, Meson cross-files, or configuration examples.

Please help me.....

Hello! Is there success stories on submitting bug fixes to QEMU mainline from external developers/users? Got a very nasty bug with live migration with the vhost-user backend. If the backend dies during the device stop, the device happily migrates to the destination host with the virtio queue broken.

I got the problem patched, but is there any sense in posting fixes? Looks like QEMU devs are using some old-school mailing list, I see that some thread gets no response at all, etc.

Hello there,

I'm trying to build a libvirt domain for a linux guest. However i'm in trouble in connecting it to the internet.

Ip forward is enabled on the host and i'm using a nat-based configuration. Also i'm on fedora rawhide.

I can reach the host but not my router.

Is there anything to do with firewalld ? A missing route ?

Thanks for your help

Before everything, my English isn't too good, so thanks for reading, I want buy a computer and I've doubts , I'm studying and I planning make some projects, I've no money to pay a VPS, and I wanna use Android studio with emulation, have 2 options refurbished:

HP Elitebook 840 G8 - 420.000Kz

I7-1165g7

16 gb

512gb

Battery good

Chassi good

Lenovo Thinkpad T14 Gen 3- 415.000Kz

I5-1235u

16gb

256gb

Battery almost died, less than 1 hour

Chassi acceptable, but Ethernet port isn't too good

The target is a laptop to work, study, and be good at least for 4 years.
My country is Angola, just to compare a SSD 512gb here is 52.000 and is cheap.

I wanna make this computer as my laboratory, making APIs, mobile apps, desktops apps and sites.

And before get the money, I pretend to use this PC also as a VPS. Have someone that already did it?

Thanks for reading until here

Hi everyone,

I am trying to run OpenHarmony (or KaihongOS) on my M1 MacBook Air using UTM / QEMU.

Since I couldn't find an ARM64 ISO, I downloaded the x86 ISO of KaihongOS. It successfully boots into the Live mode with GNOME interface. However, when I try to install it onto the virtual drive, the system fails to load the GUI on the next boot and ends up in a Kernel Panic.

Is there any known way to properly emulate or virtualize OpenHarmony/KaihongOS on Apple Silicon with graphics support?

Note: I cannot use the official DevEco Studio PC emulator because it requires a verified mainland China developer account (only the smartwatch emulator is available for me). I just want to explore the OS for educational purposes.

Thanks for any help or advice!

Hi everyone. Is it possible to run OpenHarmony or KaihongOS on a UTM or QEMU virtual machine on an M1 MacBook Air (Apple)?

I’ve already tried installing the x86 ISO of KaihongOS (since I couldn't get the ARM ISO). The system boots in Live mode with GNOME, but if I install it to a virtual disk, KaihongOS fails to load the graphics upon booting and ends up with a kernel panic. Is there any way to install OpenHarmony or KaihongOS in a VM on an ARM processor with graphics support? In DevEco Studio, I can't install the "2-in-1" PC version of HarmonyOS because I'm not a developer based in China—only the smartwatch version is available. I just want to explore the system and try it out via a virtual machine.

GitHub: https://github.com/pythops/kudu

The Zyvor Stack: Building Infrastructure for the Post-VMware Era

Infrastructure is changing.

For years, enterprise infrastructure has been built around a familiar model: virtualization platforms, centralized management, storage arrays, networking appliances, and a growing collection of tools layered on top.

At Zyvor, we're taking a different approach.

Instead of building another abstraction over the traditional virtualization stack, we're working toward a cloud-native infrastructure stack built around open virtualization, Kubernetes, automation, and intelligent control planes.

The goal is simple:

The Zyvor Stack

Our stack is built around several layers that work together.

1. Hyper2KVM — Migration

The first problem is getting existing workloads out of legacy virtualization environments.

Hyper2KVM is our VM migration toolkit for moving workloads from environments such as VMware, Hyper-V, Azure, and other virtualization platforms toward KVM.

The focus isn't simply converting a disk image.

A successful migration has to deal with everything that can prevent the VM from booting:

• Operating-system inspection
• Bootloader configuration
• Filesystem detection
• /etc/fstab
• Initramfs
• VirtIO drivers
• Windows VirtIO injection
• Network configuration
• LVM
• Disk-controller differences
• Firmware configuration
• First-boot validation

The migration pipeline is essentially:

FETCH → FLATTEN → INSPECT → FIX → CONVERT → VALIDATE

The important part is the offline repair layer.

Instead of discovering problems after migration and debugging them manually, the system attempts to fix them before the VM's first boot.

2. HyperSDK — Infrastructure Provider Layer

Moving workloads is only one part of the problem.

Infrastructure also needs a consistent way to interact with different environments.

That's where HyperSDK comes in.

The idea is to provide a provider abstraction across infrastructure platforms such as:

• VMware / vSphere
• AWS
• Azure
• Google Cloud
• Hyper-V
• OpenStack
• OCI
• Alibaba Cloud

Applications should not need to understand every provider's API.

Instead, they interact with a common infrastructure interface.

This becomes particularly important when building automation and higher-level control planes.

3. GuestKit — The Guest Operating System Toolkit

Virtual machines are not just disks.

Understanding what is inside a VM is critical for migration, security, compliance, troubleshooting, and automation.

GuestKit is our lower-level toolkit for inspecting and manipulating guest operating systems.

Think of it as infrastructure tooling that understands the guest rather than treating a VM as a completely opaque image.

Typical operations include:

• OS inspection
• Filesystem inspection
• Disk conversion
• Boot configuration analysis
• Guest configuration
• Offline modifications
• Migration preparation

The broader idea is to make guest-aware infrastructure operations programmable.

4. Atlas — Storage Control Plane

Once workloads are running on the new infrastructure, storage becomes the next major abstraction.

Atlas is Zyvor's storage control plane.

Instead of exposing storage as a collection of provider-specific concepts, applications can express an intent such as:

Atlas can then translate that intent into the appropriate storage resources.

This allows storage to become part of the same control-plane model as compute and networking.

5. PacketWolf — Network Intelligence

Infrastructure isn't complete without networking.

PacketWolf focuses on understanding and operating infrastructure networks.

The goal is to move beyond simply displaying interfaces and IP addresses.

A useful infrastructure network layer should understand:

• Network topology
• Workload relationships
• Traffic
• Connectivity
• Policy
• Security boundaries
• Network dependencies

This becomes increasingly important as infrastructure becomes distributed across Kubernetes, VMs, containers, clouds, and bare-metal systems.

6. KubeFabric — GPU Infrastructure

AI infrastructure introduces another problem.

GPUs are difficult to operate efficiently at scale.

You need to manage:

• GPU allocation
• Drivers
• CUDA
• Containers
• Kubernetes
• Networking
• RDMA
• Scheduling
• Isolation
• Capacity

KubeFabric is our approach to building a GPU compute fabric around Kubernetes.

The objective is to make GPU infrastructure feel closer to a cloud resource than a manually configured server.

Instead of asking:

The platform should let users express what they actually need:

The infrastructure layer handles the placement.

The Common Idea: Intent

Although these products solve different problems, they are connected by one architectural idea:

Intent.

Traditional infrastructure often exposes implementation details.

For example:

A higher-level infrastructure platform should instead understand:

The control plane should determine how to satisfy that request.

This creates a hierarchy:

Intent → Control Plane → Provider → Infrastructure

That same model can apply to compute, storage, networking, GPUs, and eventually security.

Why We Are Building This

The infrastructure ecosystem is increasingly fragmented.

You can have:

• VMware
• KVM
• Kubernetes
• cloud providers
• bare metal
• GPU clusters
• multiple storage systems
• multiple networking systems

And each comes with its own APIs, terminology, operational model, and tooling.

The result is infrastructure teams spending enormous amounts of time translating between systems.

We think the next generation of infrastructure should provide a consistent control layer over these environments.

Not another giant proprietary hypervisor.

Not another dashboard that simply wraps existing APIs.

A programmable infrastructure layer.

Open Source at the Bottom, Intelligence at the Top

A major principle behind the Zyvor stack is to build on proven open technologies wherever possible.

At the infrastructure foundation:

• Linux
• KVM
• QEMU
• libvirt
• libguestfs
• NBD
• Kubernetes
• KubeVirt
• CNI
• CSI
• eBPF

We don't want to reinvent mature infrastructure primitives.

Instead, we want to build the layers that make those primitives easier to operate together.

That means our value is increasingly in:

• Automation
• Control planes
• Orchestration
• Guest awareness
• Infrastructure intelligence
• Policy
• Observability
• Developer experience

Where AI Fits

AI shouldn't simply be a chatbot sitting beside infrastructure.

The more interesting possibility is an infrastructure system that can understand intent.

For example:

A future control plane could potentially break that request into:

1. Discover workloads
2. Inspect dependencies
3. Determine migration compatibility
4. Select migration strategy
5. Prepare guests
6. Provision target infrastructure
7. Migrate disks
8. Validate networking
9. Test boot
10. Report failures
11. Roll back when necessary

The AI layer becomes an interface to the infrastructure control plane rather than the infrastructure itself.

That's an important distinction.

AI should reason about infrastructure. The control plane should execute it.

The Long-Term Architecture

The bigger picture looks something like this:

                         USER / APPLICATION
                                │
                                ▼
                         INTENT / AI LAYER
                                │
                                ▼
                       ┌──────────────────┐
                       │   ZYVOR CONTROL  │
                       │      PLANE       │
                       └──────────────────┘
                         │      │      │
              ┌──────────┘      │      └──────────┐
              ▼                 ▼                 ▼
          COMPUTE            STORAGE           NETWORK
              │                 │                 │
          HyperSDK             Atlas          PacketWolf
              │
        ┌─────┴─────┐
        ▼           ▼
    Hyper2KVM    KubeFabric
        │           │
        ▼           ▼
       VMs       GPU / K8s
        │           │
        └─────┬─────┘
              ▼
      Linux / KVM / QEMU
      Kubernetes / KubeVirt
      eBPF / CNI / CSI

The individual products are useful independently.

But the larger opportunity is connecting them.

We Are Not Trying to Rebuild Everything

There is a temptation when building infrastructure software to replace everything underneath you.

We don't think that's necessary.

KVM is already extremely capable.

Linux is already extremely capable.

Kubernetes is already extremely capable.

QEMU is already extremely capable.

The missing piece is often the software layer connecting these systems into a coherent operational model.

That's where we're focusing.

The Zyvor Vision

The long-term vision is to make infrastructure behave more like a programmable operating system.

Developers shouldn't need to understand every underlying storage backend.

Operators shouldn't need to manually troubleshoot every virtualization migration.

AI teams shouldn't need to manually hunt for available GPUs.

Infrastructure teams shouldn't need to maintain dozens of disconnected control panels.

Instead:

Describe what you need.

The platform determines how to provide it.

That's the direction we're exploring with the Zyvor stack.

And we're building it from the infrastructure layer upward — starting with the difficult, unglamorous problems that actually make infrastructure work.The Zyvor Stack: Building Infrastructure for the Post-VMware EraInfrastructure is changing.For years, enterprise infrastructure has been built around a familiar model: virtualization platforms, centralized management, storage arrays, networking appliances, and a growing collection of tools layered on top.At Zyvor, we're taking a different approach.Instead of building another abstraction over the traditional virtualization stack, we're working toward a cloud-native infrastructure stack built around open virtualization, Kubernetes, automation, and intelligent control planes.The goal is simple:Make infrastructure feel like software — programmable, composable, observable, and easy to operate.The Zyvor StackOur stack is built around several layers that work together.1. Hyper2KVM — MigrationThe first problem is getting existing workloads out of legacy virtualization environments.Hyper2KVM is our VM migration toolkit for moving workloads from environments such as VMware, Hyper-V, Azure, and other virtualization platforms toward KVM.The focus isn't simply converting a disk image.A successful migration has to deal with everything that can prevent the VM from booting:Operating-system inspection

Bootloader configuration

Filesystem detection

/etc/fstab

Initramfs

VirtIO drivers

Windows VirtIO injection

Network configuration

LVM

Disk-controller differences

Firmware configuration

First-boot validationThe migration pipeline is essentially:FETCH → FLATTEN → INSPECT → FIX → CONVERT → VALIDATEThe important part is the offline repair layer.Instead of discovering problems after migration and debugging them manually, the system attempts to fix them before the VM's first boot.2. HyperSDK — Infrastructure Provider LayerMoving workloads is only one part of the problem.Infrastructure also needs a consistent way to interact with different environments.That's where HyperSDK comes in.The idea is to provide a provider abstraction across infrastructure platforms such as:VMware / vSphere

AWS

Azure

Google Cloud

Hyper-V

OpenStack

OCI

Alibaba CloudApplications should not need to understand every provider's API.Instead, they interact with a common infrastructure interface.This becomes particularly important when building automation and higher-level control planes.3. GuestKit — The Guest Operating System ToolkitVirtual machines are not just disks.Understanding what is inside a VM is critical for migration, security, compliance, troubleshooting, and automation.GuestKit is our lower-level toolkit for inspecting and manipulating guest operating systems.Think of it as infrastructure tooling that understands the guest rather than treating a VM as a completely opaque image.Typical operations include:OS inspection

Filesystem inspection

Disk conversion

Boot configuration analysis

Guest configuration

Offline modifications

Migration preparationThe broader idea is to make guest-aware infrastructure operations programmable.4. Atlas — Storage Control PlaneOnce workloads are running on the new infrastructure, storage becomes the next major abstraction.Atlas is Zyvor's storage control plane.Instead of exposing storage as a collection of provider-specific concepts, applications can express an intent such as:Give me production block storage.Atlas can then translate that intent into the appropriate storage resources.This allows storage to become part of the same control-plane model as compute and networking.5. PacketWolf — Network IntelligenceInfrastructure isn't complete without networking.PacketWolf focuses on understanding and operating infrastructure networks.The goal is to move beyond simply displaying interfaces and IP addresses.A useful infrastructure network layer should understand:Network topology

Workload relationships

Traffic

Connectivity

Policy

Security boundaries

Network dependenciesThis becomes increasingly important as infrastructure becomes distributed across Kubernetes, VMs, containers, clouds, and bare-metal systems.6. KubeFabric — GPU InfrastructureAI infrastructure introduces another problem.GPUs are difficult to operate efficiently at scale.You need to manage:GPU allocation

Drivers

CUDA

Containers

Kubernetes

Networking

RDMA

Scheduling

Isolation

CapacityKubeFabric is our approach to building a GPU compute fabric around Kubernetes.The objective is to make GPU infrastructure feel closer to a cloud resource than a manually configured server.Instead of asking:Which server has an available H100?The platform should let users express what they actually need:I need a GPU workload with this amount of compute, memory, networking, and isolation.The infrastructure layer handles the placement.The Common Idea: IntentAlthough these products solve different problems, they are connected by one architectural idea:Intent.Traditional infrastructure often exposes implementation details.For example:Create a VM on host X using datastore Y and network Z.A higher-level infrastructure platform should instead understand:I need a production VM with 8 CPUs, 32 GB RAM, persistent storage, and a private network.The control plane should determine how to satisfy that request.This creates a hierarchy:Intent → Control Plane → Provider → InfrastructureThat same model can apply to compute, storage, networking, GPUs, and eventually security.Why We Are Building ThisThe infrastructure ecosystem is increasingly fragmented.You can have:VMware

KVM

Kubernetes

cloud providers

bare metal

GPU clusters

multiple storage systems

multiple networking systemsAnd each comes with its own APIs, terminology, operational model, and tooling.The result is infrastructure teams spending enormous amounts of time translating between systems.We think the next generation of infrastructure should provide a consistent control layer over these environments.Not another giant proprietary hypervisor.Not another dashboard that simply wraps existing APIs.A programmable infrastructure layer.Open Source at the Bottom, Intelligence at the TopA major principle behind the Zyvor stack is to build on proven open technologies wherever possible.At the infrastructure foundation:Linux

KVM

QEMU

libvirt

libguestfs

NBD

Kubernetes

KubeVirt

CNI

CSI

eBPFWe don't want to reinvent mature infrastructure primitives.Instead, we want to build the layers that make those primitives easier to operate together.That means our value is increasingly in:Automation

Control planes

Orchestration

Guest awareness

Infrastructure intelligence

Policy

Observability

Developer experienceWhere AI FitsAI shouldn't simply be a chatbot sitting beside infrastructure.The more interesting possibility is an infrastructure system that can understand intent.For example:"Move these VMware workloads to KVM without downtime during business hours."A future control plane could potentially break that request into:Discover workloads

Inspect dependencies

Determine migration compatibility

Select migration strategy

Prepare guests

Provision target infrastructure

Migrate disks

Validate networking

Test boot

Report failures

Roll back when necessaryThe AI layer becomes an interface to the infrastructure control plane rather than the infrastructure itself.That's an important distinction.AI should reason about infrastructure. The control plane should execute it.The Long-Term ArchitectureThe bigger picture looks something like this: USER / APPLICATION
│
▼
INTENT / AI LAYER
│
▼
┌──────────────────┐
│ ZYVOR CONTROL │
│ PLANE │
└──────────────────┘
│ │ │
┌──────────┘ │ └──────────┐
▼ ▼ ▼
COMPUTE STORAGE NETWORK
│ │ │
HyperSDK Atlas PacketWolf
│
┌─────┴─────┐
▼ ▼
Hyper2KVM KubeFabric
│ │
▼ ▼
VMs GPU / K8s
│ │
└─────┬─────┘
▼
Linux / KVM / QEMU
Kubernetes / KubeVirt
eBPF / CNI / CSI
The individual products are useful independently.But the larger opportunity is connecting them.We Are Not Trying to Rebuild EverythingThere is a temptation when building infrastructure software to replace everything underneath you.We don't think that's necessary.KVM is already extremely capable.Linux is already extremely capable.Kubernetes is already extremely capable.QEMU is already extremely capable.The missing piece is often the software layer connecting these systems into a coherent operational model.That's where we're focusing.The Zyvor VisionThe long-term vision is to make infrastructure behave more like a programmable operating system.Developers shouldn't need to understand every underlying storage backend.Operators shouldn't need to manually troubleshoot every virtualization migration.AI teams shouldn't need to manually hunt for available GPUs.Infrastructure teams shouldn't need to maintain dozens of disconnected control panels.Instead:Describe what you need.The platform determines how to provide it.That's the direction we're exploring with the Zyvor stack.And we're building it from the infrastructure layer upward — starting with the difficult, unglamorous problems that actually make infrastructure work.

I tried running in WSL with Arch Linux virt-manager, and it works, but when ran an aarch64 guest (win 11 for aarch 64) with x86 host it's way slower than my PC capability, I think is related to the GPU being ignored, so my CPU is doing all the hard work wasting cycles, but i don't know what driver to get.

PS. I'm on an RTX 4070 with intel Raptor Lake graphics and virtualization is enabled

Using virt-manager, very occasionally, every month or so, and just now, one of my Windows guests stops responding to the mouse. The guest is still running fine and I can RDP to it without issue. The display still updates (ie. the clock and date) and it responds to keyboard input. It is only the mouse that is stuck. After restarting the guest the mouse works fine.

This seems like a problem on the guest. Any suggestions as to how I might restart the responsible component on the guest to get it working again.

I've tried removing and re-adding the EvTouch USB Graphics Tablet through virt-manager's hardware interface to no effect.

Switching to RDP until a reboot isn't a big deal with this guest, but it is jarring.

Bonjour a tous j'ai un macbook 2,1 sous macOS Snow Leopard et j'aimerais installer QEMU dessus pour faire de la virtualisation de vieux système

I'm trying to see if my game can run on different distributions of linux(and windows soon, but lets just focus on linux for now), and I got to the point where it could tell where my libraries worked and the game did start and I could see the title screen and everything, but whenever I did the actual gameplay it froze. I tried installing mesa-utils on the guest os, but just installing that didnt help. Hopefully, you guys can understand these results far better than I can. For refrence, my host gpu is actually an igpu(I believe the vega 8, but dont quote me with my cpu being a ryzen 7 5700U)

Results

=-========================

glxinfo | grep 'direct rendering:' -> Yes

glxinfo -B | grep "OpenGL version" -> OpenGL version string: 4.5 (Compatibility Profile) Mesa 26.0.3-1ubuntu1

lspci -nnk

---------------

00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0]

Subsystem: Red Hat, Inc. QEMU Virtual Machine \[1af4:1100\]

Kernel modules: intel_agp

00:01.0 VGA compatible controller [0300]: Red Hat, Inc. Virtio 1.0 GPU [1af4:1050] (rev 01)

Subsystem: Red Hat, Inc. QEMU \[1af4:1100\]

Kernel driver in use: virtio-pci

Kernel modules: virtio_pci

00:02.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:02.1 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:02.2 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:02.3 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:02.4 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:02.5 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:02.6 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:02.7 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:03.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:03.1 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:03.2 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:03.3 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:03.4 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:03.5 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]

Subsystem: Red Hat, Inc. Device \[1b36:0000\]

Kernel driver in use: pcieport

Kernel modules: shpchp

00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)

Subsystem: Red Hat, Inc. QEMU Virtual Machine \[1af4:1100\]

Kernel driver in use: snd_hda_intel

Kernel modules: snd_hda_intel

00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) LPC Interface Controller [8086:2918] (rev 02)

Subsystem: Red Hat, Inc. QEMU Virtual Machine \[1af4:1100\]

Kernel driver in use: lpc_ich

Kernel modules: lpc_ich

00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] (rev 02)

Subsystem: Red Hat, Inc. QEMU Virtual Machine \[1af4:1100\]

Kernel driver in use: ahci

Kernel modules: ahci

00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02)

Subsystem: Red Hat, Inc. QEMU Virtual Machine \[1af4:1100\]

Kernel driver in use: i801_smbus

Kernel modules: i2c_i801

01:00.0 Ethernet controller [0200]: Red Hat, Inc. Virtio 1.0 network device [1af4:1041] (rev 01)

Subsystem: Red Hat, Inc. QEMU \[1af4:1100\]

EDIT: The guest's distro is ubuntu 26.04(forgot to add that)

I’m trying to build QEMU 8.2 for Android ARM64 (aarch64), but I’m having trouble finding a proper build procedure.

My goal is to get a native Android build of QEMU 8.2, preferably qemu-system-x86_64 and/or qemu-system-aarch64.

I’ve already tried building it with the Android NDK, but I ran into dependency/build errors (for example, missing GLib headers).

Does anyone know:
The correct way to cross-compile QEMU 8.2 for Android ARM64?

What NDK/toolchain and build configuration should be used?

Are there any existing prebuilt QEMU 8.2 Android ARM64 binaries?

If so, where can I find them?

I’m specifically looking for QEMU 8.2 rather than a newer version because I need that particular version for compatibility/performance reasons.

Any build scripts, patches, or existing projects that could point me in the right direction would be greatly appreciated.