feat(machine): add Hyperlight platform support#2797
Open
danbugs wants to merge 5 commits intounikraft:stagingfrom
Open
feat(machine): add Hyperlight platform support#2797danbugs wants to merge 5 commits intounikraft:stagingfrom
danbugs wants to merge 5 commits intounikraft:stagingfrom
Conversation
Add a Hyperlight machine driver that runs Unikraft unikernels via Hyperlight micro-VMs. Register 'hyperlight' and 'hl' as platform aliases alongside firecracker/qemu/xen. Each kraft machine corresponds to a hyperlight-unikraft child process: Create prepares the config, Start spawns the process with stdout/stderr redirected to vmm.log, and Stop/Delete terminate via SIGTERM using the stored PID. This mirrors the firecracker driver's lifecycle so kraft ps, logs, stop, and rm all work naturally across kraft invocations — the VM handle doesn't need to survive in-process. The driver is pure Go and has no cgo or compile-time link to hyperlight-unikraft; it only requires the hyperlight-unikraft binary on $PATH at runtime. Default memory is 16Mi (the median of the hyperlight-unikraft example workloads); heavier guests override upward. Signed-off-by: danbugs <danilochiarlone@gmail.com>
Some components are structurally libraries but hosted in 'app-*' repos (notably app-elfloader). kraft pulls them to .unikraft/apps/<name>, yet the library-path resolver expects them under .unikraft/libs/<name> and fails with "cannot determine library path without component source". Fall back to the apps/ location when the library's expected path is missing and its name starts with 'app-'. Apply the same fallback during schema transform so downstream callers see a valid path immediately, and expose LibraryConfig.SetPath so MakeArgs can patch already-loaded libraries before the final path check. Signed-off-by: danbugs <danilochiarlone@gmail.com>
Previously the Hyperlight driver was only registered via register_linux.go; on Windows hostSupportedStrategies() returned an empty map. Add the same registration in register_windows.go so `kraft --plat hyperlight` works on Windows hosts backed by Hyper-V / Windows Hypervisor Platform. Also clarify DefaultMemory/DefaultStack comments and READMEs. Signed-off-by: danbugs <danilochiarlone@gmail.com>
Switch Start from `os/exec` to `kraftkit.sh/exec` with `WithDetach(true)`, matching the firecracker driver. The child hyperlight-unikraft process is now placed in its own process group on Linux (Setpgid) and survives the parent kraft exiting — so `kraft run` backgrounded and then detached from the terminal doesn't take the VM down with it. Also call Process.Release right after Start so the go-runtime doesn't need Wait() machinery against the child. Lifecycle is PID-tracked in machine.Status, same as firecracker. Addresses review feedback on unikraft#2636: 'the hyperlight process isn't started in detached mode'. Signed-off-by: danbugs <danilochiarlone@gmail.com>
- Point the hyperlight-unikraft install URL at the actual repo (danbugs/hyperlight-unikraft main) instead of the hypothetical hyperlight-dev/hyperlight-unikraft mirror. - Replace the manual 'cargo build + cp to /usr/local/bin' recipe with `cargo install --git ... --bin hyperlight-unikraft` — one command, ends up on PATH automatically. - Call out Windows support (the driver works on any host where hyperlight-unikraft can find a hypervisor: KVM on Linux, WHP on Windows). - Mention that direct Rust FFI is a planned follow-up to the subprocess model. Signed-off-by: danbugs <danilochiarlone@gmail.com>
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
1 participant
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.
Summary
Adds a new machine driver that runs Unikraft unikernels on Hyperlight micro-VMs.
kraft run --plat hyperlight ...launches a unikernel in a KVM/MSHV-backed (Linux) or WHP-backed (Windows) Hyperlight micro-VM, tracked end-to-end by the same PID-lifecycle machinery the firecracker driver uses.Fixes #2636.
What changed
machine/hyperlight/— new package implementing thev1alpha1.MachineServiceinterface:Create,Start,Stop,Delete,Get,List,Watch,Logs. Each machine corresponds to one detachedhyperlight-unikraftchild process whose stdout + stderr stream into<stateDir>/vmm.log.machine/platform/register_linux.go+register_windows.go— wire the driver into the Linux (KVM/MSHV) and Windows (WHP) platform registries.machine/platform/platform.go— addPlatformHyperlightand itshlalias.unikraft/{app,lib}/*— small fix so libraries pulled into.unikraft/apps/<name>(app-elfloader style) resolve correctly when MakeArgs rebuilds. Needed because the canonical hyperlight workload depends on app-elfloader.Addresses the pre-PR feedback raised in #2636.
Runtime dependency
The driver spawns a
hyperlight-unikraftbinary from danbugs/hyperlight-unikraft. One-line install:The
hyperlight-unikraftrepo is currently under my personal alias (danbugs/). Once all required Hyperlight features land upstream, the plan is to move it under thehyperlight-devorg — this PR's install URL will be refreshed at that point.Known limitations
kraft pauseunsupported — Hyperlight has no pause semantic.hyperlight-unikraftdoesn't yet provide a paravirtualized NIC; follow-up work along the lines of Firecracker's PVH networking is tracked separately.time.sleepand other interval-based timers don't block yet. The hyperlight-hosthw-interruptsfeature is enabled inhyperlight-unikraft(so vector 0x20 / IO port 107 plumbing is in place), but the Unikrafthyperlight-platformbranch still needs the guest-side pvtimer bring-up (PIC remap + IDT vector + period configuration at the right point in boot) to complete the loop. Wall-clock reads (time.time(),datetime.now()) do work today — kraftkit injects a host-side timestamp via init-data at boot and the guest adds its own monotonic delta.Tested
Ran the example workloads in danbugs/hyperlight-unikraft through this driver.
kraft ps,kraft stop,kraft rm,kraft logs --followall work across separate kraft invocations. Verified detached lifecycle — closing kraft leaves the VMM running until it exits on its own;kraft stopcleans it up afterwards.