BusDK Update

QEMU becomes a managed Bus service with proof manifests

QEMU-backed VMs now have an early managed-service path in BusDK. Instead of relying only on ad-hoc launch scripts, the QEMU bridge can be started and supervised through the Bus service lifecycle, with evidence captured in proof manifests and checked in CI.

The value is operational: virtualization infrastructure can be reviewed as a service with reproducible evidence. That matters when AI work depends on VMs, because the machines it runs on need lifecycle and proof records like other BusDK services.

June 30, 2026bus-integration-qemuQEMUproof manifests

In Brief

TL;DR

QEMU-backed VM work is moving into the managed Bus service lifecycle through a service bridge for start and supervision behavior.
Proof manifests and CI coverage make the bridge auditable instead of treating VM launches as one-off local scripts.
The shape is still early and experimental; coverage across every runtime is outside this update.

The QEMU service bridge gives BusDK a clearer boundary for virtual machines. Service lifecycle code owns when the VM starts and stops, while proof manifests record what was exercised. CI coverage keeps the bridge repeatable for reviewers and operators.

Around bus-integration-qemu that meant lifecycle hardening, isolated VM planning, guest service bridge work, and engine proof records. The VM starts and stops under the same bus services management as everything else in the stack, and its proof manifest and CI lane are recorded artifacts — so the current state is auditable without relying on a one-off operator transcript.

This remains early infrastructure. It is useful because the VM layer can be managed and evidenced like other services. The broader virtualization surface is still experimental.

See docs.busdk.com for BusDK module documentation and service integration details.