Bump Cloud Hypervisor default to v51.1

[ulziibay-kernel]

Summary

• Bumps DefaultVersion from V49_0 to V51_1 in binaries_linux.go and binaries_darwin.go
• Both v49.0 and v51.1 binaries remain embedded for standby restore compatibility
• New instances get v51.1; existing v49.0 standbys restore using their stored version

Rollout plan

1. Staging: Deploy this branch to a staging hypeman host, validate create/standby/restore/fork end-to-end
2. Production: Merge and deploy after staging validation
3. Cleanup: Remove v49.0 from SupportedVersions and embeds after all v49.0 standbys drain

Test plan

• Deploy this to staging per https://github.com/kernel/infra/actions/runs/26472165413/job/77948212446
• SSH into a host and start an instance:

root@dev-yul-hypeman-0:~# curl -s -X POST "https://hypeman.dev-yul-hypeman-0.kernel.sh/instances" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "ch-v51-test",
    "image": "docker.io/library/alpine:latest",
    "size": "512MB",
    "vcpus": 1,
    "network": {"enabled": false}
  }'

• See that event get logged in Signoz under "service.name = 'hypeman' deployment.environment = 'staging' version = 'v51.1'

Made with Cursor

---

Note

Medium Risk
Changes the hypervisor binary used for all new Linux CH instances; rollback and standby compatibility depend on keeping v49.0 embeds until old standbys drain.

Overview
Sets DefaultVersion to V51_1 in lib/vmm/binaries_linux.go and lib/vmm/binaries_darwin.go, so new Cloud Hypervisor instances that do not specify a version launch v51.1 instead of v49.0.

Embedded v49.0 and v51.1 binaries and SupportedVersions are unchanged; standby restore, cold boot, and fork still use the version stored on the instance.

^{Reviewed by Cursor Bugbot for commit 4dd009c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Firetiger deploy monitoring skipped

This PR didn't match the auto-monitor filter configured on your GitHub connection:

Any PR that changes the kernel API. Monitor changes to API endpoints (packages/api/cmd/api/) and Temporal workflows (packages/api/lib/temporal) in the kernel repo

Reason: PR modifies hypervisor binary versions in lib/vmm and related packages, not API endpoints (packages/api/cmd/api/) or Temporal workflows (packages/api/lib/temporal) as specified in the filter.

To monitor this PR anyway, reply with @firetiger monitor this.

[ulziibay-kernel]

Staging Validation Results

We validated Cloud Hypervisor v51.1 on both staging hypeman hosts (dev-yul-hypeman-0 and dev-yul-hypeman-1). The full VM lifecycle was tested: instance creation from an OCI image (nginx:alpine), boot to Running in ~4 seconds, exec into the guest (confirmed uname -a and nginx serving traffic), snapshot to standby, restore from standby back to Running, and clean deletion. All steps completed successfully with version: v51.1 confirmed in hypeman logs.

The one untested path is the full Kernel API invocation flow (Kernel API → Temporal → Hypeman), which is blocked by a pre-existing staging Kernel API issue (failed to create code volume) unrelated to the CH version change. The CH v51.1 change only affects the VMM binary that boots the guest — code volume mounts, orchestration, and callbacks are all layers above the hypervisor and are unaffected. The change is safe to merge and deploy to production.

Test Details

Test	Host	Result
Create instance (OCI image)	dev-yul-hypeman-0, dev-yul-hypeman-1	version: v51.1 ✅
VM boot	Both	Running in ~4s ✅
Exec into VM	dev-yul-hypeman-1	hello from v51.1 ✅
Exec uname	dev-yul-hypeman-1	Linux hypeman 6.12.8+ ✅
Nginx serving traffic	dev-yul-hypeman-1	Welcome to nginx! ✅
Standby (snapshot)	dev-yul-hypeman-1	has_snapshot: true ✅
Restore from standby	dev-yul-hypeman-1	Immediate Running ✅
Stop/Remove	Both	Clean ✅

Staging deploy: https://github.com/kernel/infra/actions/runs/26472165413