Refactor VM lifecycle around capabilities
Make host-integrated VM features fit a standard Go extension path instead of adding more one-off branches through vm.go. This is the enabling refactor for future work like shared mounts, not the /work feature itself. Add a daemon capability pipeline plus a structured guest-config builder, then move the existing /root work-disk mount, built-in DNS, and NAT wiring onto those hooks. Generalize Firecracker drive config at the same time so later storage features can extend machine setup without another hardcoded path. Add banger doctor on top of the shared readiness checks, update the docs to describe the new architecture, and cover the new seams with guest-config, capability, report, CLI, and full go test verification. Also verify make build and a real ./banger doctor run on the host.
This commit is contained in:
parent
9e98445fa2
commit
4930d82cb9
18 changed files with 1120 additions and 105 deletions
25
README.md
25
README.md
|
|
@ -81,6 +81,11 @@ Create and boot a VM:
|
|||
banger vm create --name calm-otter --disk-size 16G
|
||||
```
|
||||
|
||||
Check host/runtime readiness before creating VMs:
|
||||
```bash
|
||||
banger doctor
|
||||
```
|
||||
|
||||
List VMs:
|
||||
```bash
|
||||
banger vm list
|
||||
|
|
@ -162,6 +167,15 @@ Useful config keys:
|
|||
- `default_modules_dir`
|
||||
- `default_packages_file`
|
||||
|
||||
## Doctor
|
||||
`banger doctor` runs the same readiness checks the Go control plane uses for VM
|
||||
start, host-integrated features, and image builds. It reports runtime bundle
|
||||
state, core VM host tools, current feature readiness, and image-build
|
||||
prerequisites in a concise pass/warn/fail list.
|
||||
|
||||
Use it when bringing up a new machine, after changing the runtime bundle, or
|
||||
before adding new host-integrated VM features.
|
||||
|
||||
## Logs
|
||||
- daemon lifecycle logs: `~/.local/state/banger/bangerd.log`
|
||||
- raw Firecracker output per VM: `~/.local/state/banger/vms/<vm-id>/firecracker.log`
|
||||
|
|
@ -218,6 +232,17 @@ transparent `.vm` lookups on the host.
|
|||
- VMs share a read-only base rootfs image.
|
||||
- Each VM gets its own sparse writable system overlay for `/`.
|
||||
- Each VM gets its own persistent ext4 work disk mounted at `/root`.
|
||||
|
||||
## Architecture Notes
|
||||
The Go daemon is the primary control plane. VM host integrations such as the
|
||||
built-in `.vm` DNS service, NAT, and `/root` work-disk wiring now sit behind a
|
||||
capability pipeline in the daemon instead of being open-coded through the VM
|
||||
lifecycle. Guest boot-time files and mounts are rendered through a structured
|
||||
guest-config builder rather than ad hoc `fstab` string mutation.
|
||||
|
||||
That split is intentional: future host-integrated features should plug into the
|
||||
daemon capability path and `banger doctor` checks first, with the remaining
|
||||
shell helpers treated as manual workflows rather than architecture drivers.
|
||||
- Stopping a VM preserves its overlay and work disk.
|
||||
|
||||
## Rebuilding The Repo Default Rootfs
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue