Lessons from the Field: Real-World Challenges of Virtualising QNX, Android, and Linux on an Automotive Embedded Platform
As vehicles transition toward software-defined architectures, virtualisation has become a cornerstone of modern automotive system design. Running multiple operating systems each tailored for safety, infotainment, or services on a single System-on-Chip (SoC) promises improved resource utilisation, faster development cycles, and long-term scalability. While combining QNX, Android Automotive, and Linux under a hypervisor supports this vision in theory, implementing it on actual automotive hardware is significantly more complex. This article reflects on a month-long, hands-on effort to implement a virtualised automotive setup on an NXP S32G2 gateway platform, highlighting not only what worked but also where expectations collided with licensing realities, hardware intent, and ecosystem maturity.
The Architectural Vision Behind the Experiment
The original goal followed a familiar automotive HPC pattern. A hypervisor would sit at the lowest level, hosting multiple virtual machines: QNX OS for safety-critical workloads, Android Automotive for infotainment and user-facing applications, and Linux-based services for diagnostics and middleware. Within this setup, a Service-Oriented Vehicle Diagnostics (SOVD) application would demonstrate how modern diagnostics can operate in a virtualised environment. This architecture is widely discussed across the industry and frequently showcased in concept platforms. It represents a future where domain consolidation and software reuse are central to vehicle design.
However, implementing this vision required addressing constraints that are often overlooked in high-level discussions.
Licensing and Platform Compatibility: The First Reality Check
The initial plan relied on QNX SDP 8, which is available under a non-commercial license. However, the NXP S32G2 board officially supports QNX SDP 7.1, and deploying it requires a commercial agreement. This immediately limited the feasibility of using the QNX hypervisor in a practical, board-supported manner.
At the same time, the S32G2 platform is fundamentally designed as an automotive gateway, optimised for networking, security, and service aggregation not for infotainment workloads such as Android Automotive. These factors alone significantly altered the project's direction.
Choosing Xen: An Open-Source Alternative
To avoid licensing restrictions, the architecture was redesigned around the open-source Xen hypervisor, supported in the NXP Linux BSP 46. Linux served as Domain 0 (Dom0), the domain controller, and Debian Bookworm was added as a Domain U (DomU) guest.
This setup provided a flexible environment for running containerised applications and maintained a realistic automotive deployment model. It also enabled Docker-based SOVD services, which became the system's main functional objective. Although this approach differed from the original QNX-centric vision, it provided a practical solution using open tools and supported hardware.
The Hidden Cost of Time and Infrastructure
A frequently underestimated aspect of embedded automotive development is the time required for system bring-up. Building a custom NXP Linux image with Docker, PFE, and VirtIO support took nearly a week. Each build could take up to 12 hours, with frequent failures caused by configuration issues or missing dependencies. Hardware limitations increased complexity. The development host had 16 GB of RAM, while Android and BSP builds typically require more. Swap files, reduced parallelism, and overnight build cycles became standard. Storage was also a challenge, as Android source trees and build outputs approached half a terabyte, requiring repeated repartitioning of both the host and target microSD card. These challenges are rarely reflected in architectural diagrams, yet they significantly impact real-world development.
When Theory Meets OS Design Assumptions
Midway through the project, two ambitious approaches ultimately proved impractical. The first involved running QNX OS as a Xen guest. While technically possible, QNX is designed to run natively on its own hypervisor.
Porting it to Xen would require significant kernel, bootloader, and driver modifications, as well as extensive validation. Limited documentation and lack of reference implementations made this approach unsustainable.
The second attempt was to build and deploy Android Automotive OS as a Xen DomU. Although Android 14 LTS images were built, the S32G2 BSP does not officially support Android. This led to hardware compatibility issues and boot-time failures, preventing further progress.
Both efforts reinforced a key lesson: operating systems and hypervisors are not interchangeable. Their assumptions about hardware, drivers, and execution environments are critical.
A Practical Success: SOVD on Debian DomU
Despite these setbacks, the project achieved a functional outcome. Once the Debian DomU was networked, focus shifted to containerization. Initial Docker deployments faced memory constraints, requiring the DomU to be reconfigured with more RAM and CPU resources. After resolving compatibility issues, particularly by upgrading from Docker Compose v1 to v2, the SOVD stack launched successfully. Diagnostic services were accessible externally through the Debian VM’s IP address, validating the use of virtualisation and containers for automotive diagnostics. Although not the original multi-OS setup, the result was a realistic, working system on automotive-grade hardware.
Reflections on Tooling, Support, and AI Assistance
Throughout the process, gaps in documentation and fragmented community support were recurring obstacles. Many issues required experimentation instead of direct solutions. In this context, AI-based tools were valuable for debugging, configuration analysis, and hypothesis generation.
However, final decisions still relied on human judgment, including when to persist, pivot, or abandon an approach. AI accelerated progress but did not replace engineering intuition.
Closing Thoughts: Bridging Vision and Reality
This project did not result in a fully virtualized QNX–Android–Linux stack. Instead, it provided a clear understanding of the constraints that shape real automotive systems. Licensing, BSP support, hardware design, storage capacity, and build infrastructure all play decisive roles in feasibility. Gateway platforms excel at service aggregation and diagnostics but are not substitutes for infotainment-focused HPCs. Automotive engineering: progress is often incremental, hard-won, and shaped as much by limitations as by innovation. And sometimes, a partial success grounded in reality is more instructive than a perfect architecture on paper.
