Repository navigation
Add onctl restart: cold-boot a Firecracker VM from its disk, optionally on a new kernel - #1140
Merged
Merged
Conversation
…onally on a new kernel Firecracker picks the kernel at boot, and onctl had no way to boot an existing VM again: Resume restores a snapshot (old kernel and memory included), and Deploy over a dead record wipes the VM directory, rootfs and all. So moving a VM to a new kernel -- or recovering one after a host reboot killed its VMM -- meant losing its disk. - cloud.Restarter (optional interface, like ImageLister) + RestartOptions. - ProviderFC.Restart: best-effort guest fs sync, stop the VMM if alive, recreate the TAP device and boot a fresh VMM against the VM's existing rootfs (and cache disk) with the same IP, MAC, vCPUs, memory and kernel command line. --kernel-image swaps the kernel and is recorded in the metadata so later restarts keep it. Works for running, dead (host reboot) and paused VMs (the snapshot is discarded). A missing kernel/rootfs fails before touching the VM; a failed boot records the VM as dead. - Deploy and Restart share kernelArgs(), so a restarted VM comes back with exactly the network settings it was deployed with. - `onctl restart <name> [--kernel-image path] [-f]`, fc only. Tests: Restart on a running VM with a new kernel, default kernel, dead VM, paused VM, missing kernel, boot failure, not found; command flags. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WubXQDJdsuKoncpCSToz93
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1140 +/- ##
==========================================
+ Coverage 33.99% 34.54% +0.54%
==========================================
Files 50 51 +1
Lines 5509 5610 +101
==========================================
+ Hits 1873 1938 +65
- Misses 3636 3672 +36 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Firecracker chooses the kernel at boot, and onctl had no way to boot an existing VM again:
resumerestores a snapshot, with the old kernel and memory inside it;createover a dead record (e.g. after a host reboot) wipes the VM directory, including its rootfs.So moving a VM to a new kernel, or recovering one whose VMM died, meant losing its disk. This came up when boxctl-vms started booting boxes on its own kernel (cdalar/boxctl-vms#99, #100): existing boxes, including multi-node k3s clusters, could only get it by being recreated.
What
cloud.Restarter(optional interface, likeImageLister) +RestartOptions{KernelImage}.ProviderFC.Restart: best-effort guest filesystem sync, stop the VMM if it's alive, recreate the TAP device, and boot a fresh VMM against the VM's existing rootfs (and cache disk) with the same IP, MAC, vCPUs, memory and kernel command line.--kernel-imageswaps the kernel and is saved in the metadata, so later restarts keep it.deadinstead of leaving stale "running" metadata.DeployandRestartsharekernelArgs(), so a restarted VM gets exactly the network settings it was deployed with.onctl restart <name> [--kernel-image <vmlinux>] [-f](fc only; other providers get a clear "not supported").TESTING-fc.md: manual test line.Testing
go test ./pkg/cloud/ ./internal/...pass,go vet,golangci-lintclean.cmd:TestReadConfig_NoConfigDirectoryandTestCreateFlagsBindToViperfail locally on main as well (unrelated; they seem to depend on the local~/.onctl).sudo ONCTL_CLOUD=fc onctl -c /root/.onctl/onctl.yaml restart <vm> -f --kernel-image /opt/fc/images/boxctl-kernel.vmlinux, thenuname -r/ check the disk content survived.Follow-up (not in this PR)
boxctl-vms could expose this (e.g. "restart box" / automatic kernel upgrade on restart), since its agent already dispatches onctl commands.
🤖 Generated with Claude Code
https://claude.ai/code/session_01WubXQDJdsuKoncpCSToz93