Specify an AVX2-capable CPU type at VM creation #15

Merged
branderson merged 2 commits from cpu-type into main 2026-08-24 20:54:06 -07:00
Collaborator

Summary generated by LLM agent

Proxmox gives a new guest x86-64-v2-AES by default, which tops out at SSE4.2 and carries no AVX. dejima now supports Cline as a second agent harness, and Cline's CLI ships as a Bun-embedded compiled binary whose stock build requires AVX2. On a default guest it dies on SIGILL, exit 132, before printing anything, and Cline publishes no baseline build to fall back to. So a devbox built from the runbook as it stood cannot run one of dejima's two supported harnesses, and the symptom is a silent crash.

This is a VM-creation setting rather than anything the guest can fix from inside, which is why it belongs on the node-side runbook and not in docs/building-a-devbox.md.

The change is confined to proxmox/README.md §2: a CPU Type row in the creation table asking for x86-64-v3 or better, and a note under it covering the three ways this goes wrong. host works too but pins the guest to the exact CPU of the node it was created on and breaks live migration, so x86-64-v3 is named as the portable floor that still carries AVX2. A cpu: <model>,flags=... allowlist cannot add AVX2, since the flag list only toggles a small fixed set, so it has to be the model. And changing it on an existing VM needs a full stop and start, because a reboot issued inside the guest keeps the same QEMU process and therefore the same CPU model, which reads as the setting not having taken.

The note ends with a grep -qw avx2 /proc/cpuinfo check, phrased so it is also worth running on a devbox created before this section existed. Without it, an already-wrong guest is discovered by a crash with no output rather than by a check.

Nothing else in the repository referenced the VM's CPU, so no other document, script or test needed to move.

Tested: the full bats test/ suite passes, 98 of 98, including links.bats, which is the one that would catch a broken relative link or an orphaned anchor in the edited prose. The technical claims come from the handoff note, where they were established by running Cline on a guest before and after the CPU type was changed: SIGILL before, working after.

**Summary generated by LLM agent** Proxmox gives a new guest `x86-64-v2-AES` by default, which tops out at SSE4.2 and carries no AVX. dejima now supports Cline as a second agent harness, and Cline's CLI ships as a Bun-embedded compiled binary whose stock build requires AVX2. On a default guest it dies on SIGILL, exit 132, before printing anything, and Cline publishes no baseline build to fall back to. So a devbox built from the runbook as it stood cannot run one of dejima's two supported harnesses, and the symptom is a silent crash. This is a VM-creation setting rather than anything the guest can fix from inside, which is why it belongs on the node-side runbook and not in `docs/building-a-devbox.md`. The change is confined to `proxmox/README.md` §2: a CPU Type row in the creation table asking for `x86-64-v3` or better, and a note under it covering the three ways this goes wrong. `host` works too but pins the guest to the exact CPU of the node it was created on and breaks live migration, so `x86-64-v3` is named as the portable floor that still carries AVX2. A `cpu: <model>,flags=...` allowlist cannot add AVX2, since the flag list only toggles a small fixed set, so it has to be the model. And changing it on an existing VM needs a full stop and start, because a reboot issued inside the guest keeps the same QEMU process and therefore the same CPU model, which reads as the setting not having taken. The note ends with a `grep -qw avx2 /proc/cpuinfo` check, phrased so it is also worth running on a devbox created before this section existed. Without it, an already-wrong guest is discovered by a crash with no output rather than by a check. Nothing else in the repository referenced the VM's CPU, so no other document, script or test needed to move. Tested: the full `bats test/` suite passes, 98 of 98, including `links.bats`, which is the one that would catch a broken relative link or an orphaned anchor in the edited prose. The technical claims come from the handoff note, where they were established by running Cline on a guest before and after the CPU type was changed: SIGILL before, working after.
dejima-agent added 1 commit 2026-08-24 20:21:21 -07:00
Specify an AVX2-capable CPU type at VM creation
tests / runner-env (pull_request_target) Successful in 40s
tests / tests (pull_request_target) Successful in 1m0s
98c4c98532
Proxmox defaults a new guest to x86-64-v2-AES, which has no AVX. dejima
now supports Cline as a second harness, and Cline's CLI is a Bun-embedded
binary whose stock build needs AVX2: on a v2 guest it dies on SIGILL
before printing anything, with no baseline build to fall back to.

The runbook now asks for x86-64-v3 at creation time, says why not host
and why a flags allowlist cannot substitute, notes that changing it needs
a full stop/start rather than a guest reboot, and gives a /proc/cpuinfo
check for guests built before this.
branderson requested changes 2026-08-24 20:51:25 -07:00
Dismissed
@@ -109,6 +109,7 @@ before you flip it rather than after.
| System | Qemu Agent | ✓ — and see the note below, the tick alone does nothing |
| Disks | Size | 128 GB. A devbox accumulates checkouts, container images and build caches, and it is not rebuilt on a schedule to clear them |
| CPU | Cores | 4 |
| CPU | **Type** | **`x86-64-v3` or better — not the default.** See below; the default cannot run one of dejima's two harnesses |
Owner

Same here "cannot run at least one of dejima's harnesses which requires AVX2 capability"

Same here "cannot run at least one of dejima's harnesses which requires AVX2 capability"
branderson marked this conversation as resolved
@@ -125,6 +126,35 @@ channel the agent has nothing to attach to, the Summary pane shows no address,
`qm shutdown` falls back to hoping ACPI is acted on, and a snapshot of a
running VM stays crash-consistent.
**The CPU type is the one setting here a guest cannot fix later from inside.**
Owner

This just isn't true at all. There's plenty of settings (basically all of them) that a guest can't change from the inside of the VM. On top of that, the CPU type can absolutely be changed later from the Proxmox console, just not while the guest is running. Drop the hyperbole:

AVX2 is needed if you want support for Cline. Proxmox defaults a new VM to x86-64-v2-AES, which tops out at SSE4.2 and has no AVX at all. The Cline harness's CLI ships as a Bun-embedded compiled binary whose stock build needs AVX2. You'll need a CPU type which supports AVX2 if you plan to run Cline in the VM, and the minimum CPU type which supports this is x86-64-v3.

Three ways to get this wrong:
...

This just isn't true at all. There's plenty of settings (basically all of them) that a guest can't change from the inside of the VM. On top of that, the CPU type can absolutely be changed later from the Proxmox console, just not while the guest is running. Drop the hyperbole: > **AVX2 is needed if you want support for Cline.** Proxmox defaults a new VM to `x86-64-v2-AES`, which tops out at SSE4.2 and has no AVX at all. The Cline harness's CLI ships as a Bun-embedded compiled binary whose stock build needs AVX2. You'll need a CPU type which supports AVX2 if you plan to run Cline in the VM, and the minimum CPU type which supports this is `x86-64-v3`. > > Three ways to get this wrong: ...
branderson marked this conversation as resolved
@@ -127,1 +128,4 @@
**The CPU type is the one setting here a guest cannot fix later from inside.**
Proxmox defaults a new VM to `x86-64-v2-AES`, which tops out at SSE4.2 and has
no AVX at all. dejima supports Cline as one of its two agent harnesses, and
Owner

Don't mention "two" harnesses anywhere here. That number will drift rapidly as dejima takes on new harnesses and this repo shouldn't need to be updated with each newly supported harness unless necessary.

Don't mention "two" harnesses anywhere here. That number will drift rapidly as dejima takes on new harnesses and this repo shouldn't need to be updated with each newly supported harness unless necessary.
branderson marked this conversation as resolved
dejima-agent added 1 commit 2026-08-24 20:52:53 -07:00
Address review on the CPU type note
tests / runner-env (pull_request_target) Successful in 39s
tests / tests (pull_request_target) Successful in 1m2s
4cf4265ac1
State the requirement as Cline needing AVX2 rather than as a claim about
what a guest can fix from inside, which was both overstated and wrong:
the type is changeable from the console, just not while the VM runs.
Drop the harness count, which will drift as dejima adds harnesses.
branderson approved these changes 2026-08-24 20:53:58 -07:00
branderson merged commit a64cbb93b9 into main 2026-08-24 20:54:06 -07:00
Sign in to join this conversation.