Cuts the daemon-managed guest-session machinery (start/list/show/
logs/stop/kill/attach/send). The feature shipped aimed at agent-
orchestration workflows (programmatic stdin piping into a long-lived
guest process) that aren't driving any concrete user today, and the
~2.3K LOC of daemon surface area — attach bridge, FIFO keepalive,
controller registry, sessionstream framing, SQLite persistence — was
locking in an API we'd have to keep through v0.1.0.

Anything session-flavoured that people actually need today can be
done with `vm ssh + tmux` or `vm run -- cmd`.

Deleted:
- internal/cli/commands_vm_session.go
- internal/daemon/{guest_sessions,session_lifecycle,session_attach,session_stream,session_controller}.go
- internal/daemon/session/ (guest-session helpers package)
- internal/sessionstream/ (framing package)
- internal/daemon/guest_sessions_test.go
- internal/store/guest_session_test.go
- GuestSession* types from internal/{api,model}
- Store UpsertGuestSession/GetGuestSession/ListGuestSessionsByVM/DeleteGuestSession + scanner helpers
- guest.session.* RPC dispatch entries
- 5 CLI session tests, 2 completion tests, 2 printer tests

Extracted:
- ShellQuote + FormatStepError lifted to internal/daemon/workspace/util.go
  (only non-session consumer); workspace package now self-contained
- internal/daemon/guest_ssh.go keeps guestSSHClient + dialGuest +
  waitForGuestSSH — still used by workspace prepare/export
- internal/daemon/fake_firecracker_test.go preserves the test helper
  that used to live in guest_sessions_test.go

Store schema: CREATE TABLE guest_sessions and its column migrations
removed. Existing dev DBs keep an orphan table (harmless, pre-v0.1.0).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-20 12:47:58 -03:00

2.9 KiB

Raw Blame History

Advanced flows

banger vm run covers the common sandbox case. This doc is for the rest: scripting, arbitrary images, custom rootfs stacks, long-lived guest processes.

`vm create` — the low-level primitive

Use when you want to provision without starting, or when you need to script VM creation piecewise.

banger vm create --image debian-bookworm --name testbox --no-start
banger vm start testbox
banger vm ssh testbox
banger vm stop testbox
banger vm delete testbox

Sweep every non-running VM (stopped, created, error) with:

banger vm prune          # interactive confirmation
banger vm prune -f       # skip the prompt

vm create is synchronous by default, but on a TTY it shows live progress until the VM is fully ready.

`image pull <oci-ref>` — arbitrary container images

For images outside banger's catalog, pull from any OCI registry:

banger image pull docker.io/library/alpine:3.20 --kernel-ref generic-6.12

Layers are flattened, ownership is fixed (setuid binaries, root-owned config preserved), banger's guest agents are injected, and a first-boot systemd service installs openssh-server via the guest's package manager so the VM is reachable on first boot.

See docs/oci-import.md for supported distros, caveats, and the internal/imagepull design.

`image register` — existing host-side stack

If you already have an ext4 rootfs, a kernel, optional initrd, and optional modules as files on disk:

banger image register --name base \
  --rootfs /abs/path/rootfs.ext4 \
  --kernel-ref generic-6.12

You can mix --kernel-ref (a cataloged kernel) with --rootfs from disk, or pass --kernel /abs/path/vmlinux for a one-off kernel.

For reproducible custom images, write a Dockerfile and publish it to an image catalog. See docs/image-catalog.md.

Workspace primitive

vm run ./repo (see README) handles the common case. For a manual flow against an already-running VM, vm workspace prepare materialises a local git checkout into the guest:

banger vm workspace prepare <vm> ./other-repo --guest-path /root/repo

Default guest path is /root/repo; default mode is a shallow metadata copy plus tracked and untracked non-ignored overlay. For repositories with submodules, pass --mode full_copy.

Inspecting boot failures

When a VM's create flow errors ("ssh did not come up within 90s" or similar), the VM is kept alive for inspection:

banger vm logs <name> — the firecracker serial console output, the best window into a stuck boot (systemd unit failures, kernel panics, missing modules).
banger vm ports <name> — what's listening in the guest. Works as long as banger's vsock agent has come up, even if SSH is wedged.
banger vm show <name> — daemon-side state (IP, PID, overlay paths).

--rm on vm run intentionally does NOT fire when the initial ssh wait times out, so the VM stays around for post-mortem.

2.9 KiB Raw Blame History