Support Running on Hyperlight

[craciunoiuc]

Feature request summary

KraftKit, the companion tool used by Unikraft can be used also to run unikernels locally using various hypervisors. Currently, KraftKit supports both QEMU and Firecracker as KVM VMMs. It also supports Xen through the use of xl toolstack.

To increase support for other tools, this project aims to add support for Hyperlight, a new VMM using the Linux kvm module for lightweight virtualization.
Similar to both the QEMU and Firecracker packages, a new one needs to be created for Hyperlight, such that the command kraft run would be able to run unikernels using Hyperlight as the underlying VMM.

Development will be incremental, starting with basic "Hello World" functionality, and later adding support for networking, storage and other features.

It is not guaranteed that the current Unikraft kernel has support for running under hyperlight. Even so, work on kraftkit can happen in parallel to that track as kraftkit should correctly interface with hyperlight first.
Afterwards, preliminary work should be done to have at least the hello-world C kernel running under it.

Describe alternatives

Only alternative right now is to build it and run it by hand.

Related architectures

x86_64

Related platforms

hyperlight

Additional context

No response

[craciunoiuc]

I think something wrong happened, this shouldn't be closed?

[rohan-019]

Hi @craciunoiuc,

I’d like to contribute Hyperlight support to KraftKit. I’ve started reviewing the existing QEMU and Firecracker backends to understand how the VMM drivers are structured and integrated.

Before drafting a design proposal, I wanted to confirm whether there is an existing abstraction layer that should be extended for a new VMM, or if some refactoring would be expected as part of this work.

I’d appreciate any guidance on the intended architectural direction.

[craciunoiuc]

No, this needs to be created from scratch

[rohan-019]

Thanks for confirming that this should be created from scratch.

After reviewing the QEMU and Firecracker backends, my understanding is that QEMU is more CLI-oriented with broader device modeling, while Firecracker follows a more minimal, KVM-based microVM approach with structured lifecycle handling.

Since Hyperlight is also KVM-based and lightweight, I’m inclined to align its integration closer to the Firecracker-style backend rather than the QEMU one.

My tentative approach would be:

1. Introduce a dedicated hyperlight backend under the runtime layer.
2. Implement minimal VM lifecycle management sufficient to boot a “Hello World” unikernel.
3. Extend networking and storage support incrementally.
4. Evaluate whether introducing a small shared VMM interface (e.g., start/stop/configure) would help reduce duplication across backends.

Does this direction align with your expectations, or would you prefer a different structural approach?

Additionally, is there any prior groundwork, experimental branch, or preparatory task you would recommend addressing before moving forward?