fix(snap): ship the VM compute driver by alexclewontin · Pull Request #2894 · NVIDIA/OpenShell

alexclewontin · 2026-08-22T02:15:07Z

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)

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 · 2026-08-22T02:15:10Z

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.

github-actions · 2026-09-06T08:28:38Z

This pull request has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity.

alexclewontin · 2026-09-10T23:18:40Z

This pull request has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity.

keep this alive

olivercalder

LGTM, thanks!

olivercalder · 2026-09-23T15:31:31Z

+
+The snap ships `openshell-driver-vm` at `/usr/libexec/openshell/openshell-driver-vm`, exposed
+through a snapcraft `layout:` symlink. To enable it, set `compute_drivers = ["vm"]` in
+`$SNAP_COMMON/gateway.toml`, then connect the `kvm` interface and restart the service:


How does setting this interact with OPENSHELL_COMPUTE_DRIVER, as in https://github.com/NVIDIA/OpenShell/pull/2250/files#diff-9f4438d00ff0b9f13896fd034278896ec94153fc2a5733b1852cbfce7ecaff77R450 ?

FWIW snapcraft.yaml never sets that variable by default, it seems it's just something which is currently in the release-canary.yml, though it is present for various packages (macos, kubernetes, fedora, ubuntu), and actually isn't present for the ubuntu-snap task at the moment.

elezar

The underlying packaging approach looks sound, but these items need to be addressed before merge:

Rebase and adapt this change to the current release artifact pipeline. Current main uses the build-vm-driver job and raw openshell-driver-vm-<triple> artifacts; retaining the older build-driver-vm-linux dependency and driver-vm-linux-* download path would break the Snap build. Preserve the current Snap canary Docker sandbox exercise and add the VM layout assertion alongside it.
Update the installation guidance for gateway schema version 2. compute_drivers = ["vm"] is now rejected; the supported setting is compute_driver = "vm". As written, an operator following docs/about/installation.mdx after the required rebase would prevent the gateway from starting.
Correct or substantiate the state persistence statement in docs/about/installation.mdx:155-157. Snap documents revision-scoped SNAP_DATA and SNAP_USER_DATA as copied or snapshotted across refresh and revert operations, so saying the default state does not persist across refreshes is misleading without evidence specific to this daemon path.

Please also update .agents/skills/test-release-canary/SKILL.md to cover the new VM-driver assertion and fix the truncated /usr/libexec/openshell/openshe path in architecture/build.md:143.

GitHub currently reports the branch as conflicting, and Branch Checks plus Helm Lint have not completed, so the rebased result will need fresh CI validation.

johntmyers · 2026-09-23T21:42:02Z

gator-agent

Blocked

Gator is blocked because this branch conflicts with main, and the current head predates the release-pipeline and gateway-schema changes it needs to integrate with.

Thanks @elezar. I checked your maintainer review against the current PR metadata: GitHub confirms the branch is not mergeable, and the current head still needs the release artifact pipeline rebase, schema-v2 documentation correction, persistence wording correction or evidence, release-canary skill update, and truncated architecture path fix you identified.

Next action: @alexclewontin, rebase onto current main, address @elezar's requested changes, and push the updated branch. Gator will then review the new head before dispatching E2E.

Gator metadata

Head SHA: f41e9a127dfcdb4cb5d086de2f512892317585a2
Base SHA: 2f7fb65591ee5746217ace154afc0aa6bf1afc6d
Merge base SHA: 56c45a997e32fed2ffcc95633e72335162b74676
Patch ID: 26b1da0ac93b60f68792ccc7f73d0c908a3463db
Gator payload: 9
Review mode: initial
Next state: gator:blocked
Blocked reason: merge_conflict

github-actions · 2026-10-16T08:33:03Z

This pull request has had no activity for 14 days and is now marked stale.

alexclewontin requested review from a team, derekwaynecarr, mrunalp and sjenning as code owners August 22, 2026 02:15

alexclewontin changed the title ~~fix(snap): ship a functional VM compute driver~~ fix(snap): ship the VM compute driver Aug 22, 2026

github-actions Bot added the state:stale Inactive item at risk of automatic closure. label Sep 6, 2026

github-actions Bot removed the state:stale Inactive item at risk of automatic closure. label Sep 11, 2026

olivercalder approved these changes Sep 23, 2026

View reviewed changes

elezar requested changes Sep 23, 2026

View reviewed changes

johntmyers added the gator:blocked Gator is blocked by process or repository gates label Sep 23, 2026

johntmyers removed the gator:blocked Gator is blocked by process or repository gates label Oct 1, 2026

olivercalder mentioned this pull request Oct 15, 2026

feat(snap): ship the VM driver in the snap and use it by default #4627

Open

5 of 6 tasks

github-actions Bot added the state:stale Inactive item at risk of automatic closure. label Oct 16, 2026

Navigation Menu

Repository navigation

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

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

alexclewontin commented Aug 22, 2026 •

edited

Loading

Uh oh!

copy-pr-bot Bot commented Aug 22, 2026

Uh oh!

github-actions Bot commented Sep 6, 2026

Uh oh!

alexclewontin commented Sep 10, 2026

Uh oh!

olivercalder left a comment

Uh oh!

olivercalder Sep 23, 2026

Uh oh!

elezar left a comment

Uh oh!

johntmyers commented Sep 23, 2026

Uh oh!

github-actions Bot commented Oct 16, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

alexclewontin commented Aug 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Related Issue

Changes

Testing

Checklist

Uh oh!

copy-pr-bot Bot commented Aug 22, 2026

Uh oh!

github-actions Bot commented Sep 6, 2026

Uh oh!

alexclewontin commented Sep 10, 2026

Uh oh!

olivercalder left a comment

Choose a reason for hiding this comment

Uh oh!

olivercalder Sep 23, 2026

Choose a reason for hiding this comment

Uh oh!

elezar left a comment

Choose a reason for hiding this comment

Uh oh!

johntmyers commented Sep 23, 2026

Blocked

Uh oh!

github-actions Bot commented Oct 16, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

alexclewontin commented Aug 22, 2026 •

edited

Loading