Skip to content

fix(snap): ship the VM compute driver - #2894

Open
alexclewontin wants to merge 1 commit into
NVIDIA:mainfrom
alexclewontin:fix/snap-vm-compute-driver/alexclewontin
Open

fix(snap): ship the VM compute driver#2894
alexclewontin wants to merge 1 commit into
NVIDIA:mainfrom
alexclewontin:fix/snap-vm-compute-driver/alexclewontin

Conversation

@alexclewontin

@alexclewontin alexclewontin commented Aug 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

The OpenShell snap never packaged it the vm compute driver binary, so selecting it crash-looped the gateway. This stages openshell-driver-vm in the snap, exposes it at the conventional /usr/libexec/openshell path via a snapcraft layout:, and vendors the e2fsprogs tooling the driver shells out to. A VM sandbox now boots from an installed snap.

Related Issue

No issue required: localized packaging bug fix, and the diff plus verification below carries enough context to review the decision and implementation together.

Changes

  • snapcraft.yaml
    • Install openshell-driver-vm to $SNAP/usr/libexec/openshell/ and add a top-level layout: symlinking /usr/libexec/openshell onto it, so the gateway's existing search path resolves inside confinement with no driver_dir pin.
    • Add the kvm plug to the gateway app so the driver can open /dev/kvm.
    • Add an e2fsprogs part staged into $SNAP/usr/sbin.
  • .github/workflows/snap-package.yml — download and stage the driver-vm-linux-<arch> artifact; include the driver in the staging completeness check.
  • .github/workflows/release-dev.yml, release-tag.yml — build-snap now depends on build-driver-vm-linux.
  • .github/workflows/release-canary.yml — assert the driver resolves at its layout path inside the installed snap.
  • tasks/ci.toml — set OPENSHELL_VM_RUNTIME_COMPRESSED_DIR for build:rust:snap and fail loudly when the runtime is absent.
  • Docs: snap VM driver setup in docs/about/installation.mdx, runtime layout in architecture/build.md, packaging and e2fsprogs notes in crates/openshell-driver-vm/README.md.

Testing

  • mise run pre-commit passes
  • Unit tests added/updated — none: packaging-only change, no Rust behavior modified
  • E2E tests added/updated (if applicable) — no automated VM e2e; a release-canary assertion covers driver presence and layout resolution. Booting a microVM needs nested virtualization on the runner, which the canary environment does not provide.

Manual end-to-end on Ubuntu 26.04, amd64, strict confinement:

  • Packed the snap with real (non-stub) binaries and installed it with --dangerous.
  • Verified meta/snap.yaml carries the layout: mapping and kvm in the gateway plugs; unsquashfs shows the driver at usr/libexec/openshell/openshell-driver-vm.
  • Confirmed layout resolution under confinement: test -f /usr/libexec/openshell/openshell-driver-vm (the exact check resolve_compute_driver_bin performs) is true, and the binary executes through that path.
  • Created a VM sandbox end to end against the snap daemon and exec'd into the guest:
$ openshell sandbox list
NAME           CREATED              PHASE
daemonvm-test  2026-08-22 02:00:05  Ready

$ openshell sandbox exec -n daemonvm-test -- sh -c 'uname -a; id; nproc'
Linux daemonvm-test 6.12.76 #1 SMP PREEMPT_DYNAMIC x86_64
uid=998(sandbox)  nproc=2  MemTotal=2075496 kB

nproc and MemTotal match the configured vcpus = 2 / mem_mib = 2048, confirming the VM came from the driver.

Checklist

  • Follows Conventional Commits
  • Commits are signed off (DCO)

@alexclewontin
fix(snap): ship a functional VM compute driver
f41e9a1 
The snap advertised the vm compute driver but never staged its binary, so
selecting it crash-looped the gateway with "vm compute driver binary not
found". Stage openshell-driver-vm and expose it at the conventional
/usr/libexec/openshell path with a snapcraft layout symlink, and add the
kvm plug the driver needs to reach /dev/kvm.

Sandbox creation then failed while formatting the rootfs. core24 ships
mke2fs, mkfs.ext4 and debugfs under /usr/sbin, but the snap AppArmor
profile denies execve on base-snap sbin binaries: they resolve on PATH and
then fail with EACCES, so a presence check cannot detect the problem.
Vendor e2fsprogs into $SNAP/usr/sbin, which the snap PATH already prefers.

Point build:rust:snap at the VM runtime directory. Without
OPENSHELL_VM_RUNTIME_COMPRESSED_DIR the driver's build.rs embeds empty stub
resources and exits 0, producing a binary that passes --version and only
fails later at sandbox creation; add a precondition so a stub build fails
loudly instead.

Cover the packaging in release-canary so a future regression that drops the
driver or breaks the layout is caught before publishing.

Verified by packing the snap, installing it, and creating a VM sandbox end
to end: the guest boots and exec returns from inside the microVM.

Signed-off-by: Alex Lewontin <alex.lewontin@canonical.com>
@copy-pr-bot

copy-pr-bot Bot commented Aug 22, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@alexclewontin alexclewontin changed the title fix(snap): ship a functional VM compute driver fix(snap): ship the VM compute driver Aug 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@mrunalp mrunalp Awaiting requested review from mrunalp mrunalp is a code owner
@sjenning sjenning Awaiting requested review from sjenning sjenning is a code owner
@derekwaynecarr derekwaynecarr Awaiting requested review from derekwaynecarr derekwaynecarr is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@alexclewontin