Repository navigation
Description
Problem Statement
The VM driver currently has no way to share a host directory into the sandbox
The Docker and Podman drivers already solve this via --driver-config-json's mounts field ({"docker":{"mounts":[{"type":"bind","source":...,"target":...}]}}), documented in the
sandbox-compute-drivers reference.
There's no VM-driver equivalent, so a project that needs a live, bidirectional view of a host working directory (e.g. so a coding agent inside the
sandbox can edit files and have the host see the changes immediately, and vice versa) cannot use the VM driver at all today.
Proposed Design
Introduce a VM driver's --driver-config-json schema with a mounts field:
{"vm": {"mounts": [
{"source": "/host/path", "target": "/sandbox/path", "read_only": false}
]}}The field names intentionally match the concept the operator cares about (a host path made available at a guest path).
Internally:
- The VM driver already depends on libkrun, which supports host-directory sharing as a first-class feature via
krun_add_virtiofs(ctx_id, tag, host_path). It defines a tag plus a host path. There's no host-specified mount point in that primitive; virtiofs only exports a directory under a tag. Therefore on the guest side it has to be mounted viamount -t virtiofs <tag> <path>. - The guest-side
mount -t virtiofs <tag> <target>would need to run during the VM driver's own boot/supervisor sequence, before handing off to the sandboxed process - mounts are a create-time-only option, consistent with how Docker
driver mounts are also specified at sandbox create rather than added to a running sandbox.
Alternatives Considered
- One-shot --upload at sandbox-create time. Already supported today, driver-agnostic. Rejected as a full substitute because it's a point-in-time snapshot, not a live bidirectional sync. Host edits during the session aren't reflected in the sandbox and vice versa.
Agent Investigation
No response
Checklist
- I've reviewed existing issues and the architecture docs
- This is a design proposal, not a "please build this" request
Activity
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1
benoitf commentedon Sep 18, 2026
I'll work on it for macOS/libkrun
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1 (NVIDIA#3451)
SidShaytay commentedon Oct 1, 2026
Could you confirm whether #2585 will cover Linux/KVM hosts? Any Fedora Silverblue specific constraints we should plan for?