mirror of https://github.com/agent-substrate/substrate.git synced 2026-10-02 03:24:42 +08:00

Files

T

Benjamin Elder f7f8727ae8 microvm: bump runtime assets to kata 4.0.0 + virtiofsd v1.14.0 (#506 )

- We no longer need to compile virtiofsd when installing for amd64, we
still need to for arm64 (no upstream release)
- Drop-in compatible, only updating the scripts that manage obtaining
the binaries, and the versions / hashes in the config.

- [x] Tests pass
- [x] Appropriate changes to documentation are included in the PR

2026-07-23 18:45:08 -04:00

assemble.sh

microvm: bump runtime assets to kata 4.0.0 + virtiofsd v1.14.0 (#506 )

2026-07-23 18:45:08 -04:00

README.md

microvm MVP cleanup: align rootfs behavior to gvisor, ... (#313 )

2026-06-26 20:02:11 -07:00

stage-to-gcs.sh

microvm MVP cleanup: align rootfs behavior to gvisor, ... (#313 )

2026-06-26 20:02:11 -07:00

stage-to-rustfs.sh

microvm MVP cleanup: align rootfs behavior to gvisor, ... (#313 )

2026-06-26 20:02:11 -07:00

README.md

Micro-VM runtime assets + counter demo (kind, fetch-not-bake)

The microvm runtime (cmd/ateom-microvm, kata + cloud-hypervisor) fetches its toolchain at runtime — nothing kata-specific is baked into the worker image. ateom drives the kata-agent directly (no kata shim, no containerd). Each actor container's rootfs is an overlay of a read-only lower (the OCI image, served into the guest over virtio-fs by virtiofsd) and a writable upper on a guest tmpfs, so virtiofsd is part of the asset set. The asset set is five files:

cloud-hypervisor — the VMM binary (fetched from its release)
virtiofsd — the virtio-fs daemon serving the RO lower (built from source; see assemble.sh)
vmlinux — the guest kernel (from kata-static)
rootfs.img — the guest rootfs image (from kata-static)
configuration-clh.toml — the base kata config (from kata-static)

These helpers assemble the asset set for your node arch, stage it into the cluster's rustfs S3 bucket, and the demo manifest's SandboxConfig points at it. When /dev/kvm is available, hack/create-kind-cluster.sh mounts it into the node and labels the node ate.dev/sandboxClass=microvm.

Tip

hack/run-microvm-demo.sh automates the full bring-up below (assets, control plane, demo apply) for kind OR GKE without editing committed files. The steps here are the manual equivalent.

Steps (run on a KVM-capable Linux host matching the node arch)

Assemble assets for your arch:
```
ARCH=arm64 hack/microvm-assets/assemble.sh
```
Copy the printed sha256 sums into the SandboxConfig spec.assets in demos/counter/counter-microvm.yaml.tmpl (the committed values are arm64; other arches differ).

Bring up the cluster + control plane:

hack/create-kind-cluster.sh        # mounts /dev/kvm, labels node ate.dev/sandboxClass=microvm
hack/install-ate-kind.sh           # control plane + rustfs (bucket: ate-snapshots)

Stage assets into rustfs:

OUT="$PWD/microvm-assets-arm64" hack/microvm-assets/stage-to-rustfs.sh

Apply the demo + drive it:
```
BUCKET_NAME=ate-snapshots envsubst < demos/counter/counter-microvm.yaml.tmpl | kubectl apply -f -
```
Create an actor from counter-microvm, hit the in-RAM counter to increment it, suspend (checkpoint), resume on a different worker pod, and confirm the count continues — proving the guest-memory snapshot round-tripped across pods.

Notes

assets is single-arch (unlike runsc's amd64/arm64): stage assets matching the node arch.