pidOf trusted any live PID from the pidfile. After a VM is killed (e.g. an
agent-restart cgroup kill) its stale pidfile can hold a PID the kernel has
reused for an unrelated process, so the VM falsely reported "running" —
Recover then skipped it and it stayed dead in drift. pidOf now confirms
/proc/<pid>/cmdline references the VM's state dir before trusting it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Enables migrating real services (config/cert dirs, stateless) to
unikernels. Volume host dirs are copied into a per-VM staging tree
mirroring guest paths; the ops config goes in the staging root with the
top-level dirs in Dirs, so ops bakes them at the right absolute paths.
(Staging is required — an absolute /srv MapDirs source makes ops descend
into the agent's podman overlay storage and fail.) A component may set
network = "user" to use QEMU user-mode NAT instead of the isolated
bridge (Phase-1 networking for first migrations, before a gateway proxy).
Verified: mcat (the MCIAS policy tester) deployed as a Nanos unikernel
via 'mcp deploy', booting with its baked /srv/mcat config+certs, serving
HTTPS verified against the platform CA, configured against MCIAS.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When the mcp-br0 bridge exists, the agent runs unikernels on it instead
of QEMU user-mode networking: each VM gets a TAP device on the bridge
and a static 10.99.0.0/24 IP (baked into the Nanos image via ops
RunConfig). With the host firewall dropping off-bridge VM traffic and no
NAT, a VM can reach only the gateway -- making mc-proxy mediation
mandatory by topology rather than convention.
- runtime/qemu.go: bridge mode (createTAP/destroyTAP, IP allocator,
deterministic MAC, static-IP ops config, VMAddr for proxy backends).
- agent auto-enables bridge mode when /sys/class/net/mcp-br0 exists.
Verified on straylight: uktest unikernel boots on mcp-br0 at 10.99.0.2,
serves via the gateway, TAP enslaved to the bridge; bridge has no uplink
and off-bridge forwarding is dropped.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Implements the hypervisor design's Phase 1: a second runtime.Runtime
backend (QEMU) that runs each service component as a Nanos unikernel VM
instead of a podman container, selected per-component via a new
runtime = "unikernel" service-def field.
- internal/runtime/qemu.go: QEMURuntime. Pull extracts the ELF from the
OCI image; Run does `ops build` + boots qemu-system-x86_64 with KVM,
user-mode net port-forwards, QMP control socket and serial console log;
Stop/Remove/Inspect/List/Logs map onto VM lifecycle + state dir.
- proto/registry/servicedef: add runtime, memory_mb, vcpus fields
(registry migration 5).
- agent: holds both runtimes; runtimeFor() selects per component;
listAllContainers() merges containers + VMs so drift/status see both.
Unikernel runtime auto-enables on nodes with /dev/kvm + ops.
Validated end-to-end on straylight: a test service deploys via
`mcp deploy --direct`, boots as a Nanos unikernel, serves HTTP through
the agent port-forward, and reports running via `mcp status`/`mcp logs`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
