openshell-driver-vm v0.0.40 hangs during MicroVM initialization on macOS M1

[ShivaKumar0786]

Agent Diagnostic

Investigated sandbox creation failures on Apple Silicon Macs using the MicroVM runtime. Traced the sandbox creation workflow through openshell-driver-vm (v0.0.40) and verified the execution path using driver logs, sandbox filesystem artifacts, process inspection, and manual rootfs extraction testing.

The driver successfully resolves the container image, creates the sandbox directory structure, and extracts the root filesystem (~4.5 GB). However, during VM startup, the process hangs indefinitely while initializing the MicroVM through libkrun. No libkrun process is launched, no additional logs are emitted, and the operation eventually fails with a timeout error.

Description

Sandbox creation fails with a timeout error. The openshell-driver-vm process hangs indefinitely during libkrun VM initialization, preventing the sandbox from starting.

Reproduction Steps

Configure OpenShell to use the MicroVM driver (openshell-driver-vm).
Run a command that creates a new sandbox.
Observe sandbox initialization progress.
Wait for the operation to complete.
The sandbox creation eventually fails with a timeout error.
Review driver logs and observe that logging stops after image resolution/rootfs extraction.
Verify that no libkrun VM process is started.

Environment

OS: macOS (ARM64 / Apple Silicon)
Hardware: M1 Mac
Driver: openshell-driver-vm v0.0.40
VM Runtime: libkrun

Logs

Agent-First Checklist

• I pointed my agent at the repo and had it investigate this issue
• I loaded relevant skills (e.g., debug-openshell-cluster, debug-inference, openshell-cli)
• My agent could not resolve this — the diagnostic above explains why

[TaylorMutch]

📋 triage-agent

Classification: needs-more-info

This is a credible report, but it cannot be confirmed against the current VM driver from the information provided.

The report targets v0.0.40. That version booted libkrun from an extracted host directory through the old virtiofs root path. PR #1263 replaced that pipeline with cached ext4-backed root disks starting in v0.0.43, materially changing the code between rootfs preparation and guest boot. I did not find a matching duplicate or an explicit fix for this exact hang, so it would be premature to close it as fixed.

One diagnostic detail is also ambiguous: libkrun is loaded into the VM launcher as a library, and the launcher forks a worker before calling krun_start_enter; there is not necessarily a separately named libkrun executable to observe in the process list.

Could you retest with the current release (v0.0.82 or newer) and provide:

• the exact macOS version, Mac model/chip, RAM, and available disk space;
• the exact image reference or digest and the sandbox creation/configuration command;
• versions of the CLI, gateway, and VM driver;
• driver debug logs (RUST_LOG=openshell_driver_vm=debug), including the last lines around spawning VM launcher and launcher spawned;
• the sandbox state-directory listing, rootfs-console.log, and gvproxy.log;
• a process tree rooted at the VM driver/launcher PID while it is hung; and
• the final timeout error and which command or component emitted it.

If it no longer reproduces, we can close this as obsolete after the #1263 VM boot redesign. If it still reproduces, those details should distinguish runtime loading, krun_create_ctx, networking setup, Hypervisor.framework entry, and guest boot.