Build a Unikernel that runs WebAssembly
a project by flavio_castelli
Updated almost 3 years ago. 5 hacker ♥️. 2 followers.

Project Description

This project aims to build a unikernel that has a sole purpose: run WebAssembly applications.

Unikernels offer a limited attack surface and theoretically can provide better performance compared to running the same application on top of a regular operating system. However, running applications on top of unikernels is not an easy tasks. Some might just work out of the box, others will require quite some efforts to be ported.

WebAssembly is a binary application format. A developer write their application using their favorite programming language, then compile it using the WebAssembly target. This produces a Wasm module, that can be run on top of a WebAssembly runtime. The runtime abstracts the underlying operating system and architecture, making the Wasm module capable of running everywhere. The WebAssembly runtime is also in charge of exposing a series of capabilities that can be leveraged by the WebAssembly guest. These capabilities could be system-related (like interacting with the filesystem, this is what WASI does) or could be functionalities provided by a specific platform (like accessing Key/Value stores, implementing http endpoints,... this is what platforms like Spin or Spiderlightning offer).

Why should we have a unikernel that runs WebAssembly:

  • To improve security. Each WebAssembly runtime executes the WebAssembly code inside of a dedicated sandbox. This isolates the Wasm workloads from each other and from the host. However this is all done in software. By using a unikernel, we will be running the application on a host (the unikernel) that as a limited attack surface, plus it will be placed inside of a traditional VM that offers better isolation capabilities.
  • To go fast. We could just place a regular WebAssembly runtime inside of a VM and call it a day (like running that inside of kata for example). However, having a super limited use case, I think we can build a really optimized system (à la firecraker)

Why I think this has higher chances of adoption compared to traditional "wanna run everything" unikernels:

  • WebAssembly modules have clear boundaries. The set of capabilities offered is set by the platform (Spin, Spiderlightning) is limited. That reduces the amount of scenarios the unikernel must support.
  • A better developer experience. A developer will build an application targeting a certain platform (Spin, Spiderlightning). This will produce a Wasm module that can be run, unchanged, by a regular WebAssembly runtime, including this unikernel. Both the regular WebAssembly runtime and the unikernel will implement the same set of capabilities. The WebAssembly guest won't even notice where its being ran.

Why am I doing this

I've always been fascinated by unikernels and I'm deeply into WebAssembly. I think there's a purpose for the two things to play together, as described above.

State of the project

I've a running POC. The unikernel is based on rusty-hermit, a unikernel written in Rust.

I've a unikernel application that is capable of running the unmodified WebAssembly module produced by the Spiderlightning key-value demo.

The unikernel is running inside of qemu, using kvm.

Goal for this Hackweek

Main goal - run WebAssembly

The main goal is be able to run the http server demo from Spiderlightning. I don't care about being able to run WASI modules, right now I just want to target some of the interfaces offered by Spiderlightning.

I don't need external help to achieve this goal.

Virtualization goals - HELP NEEDED

As an additional goal, I would like to replace the usage of qemu with something that is custom built.

We need a stripped down hypervisor that:

  • Offers a network stack based on virtio - this is what hermit supports
  • [Optional] offers a virtio disk backed by virtiofs - that's the only type of disk supported by hermit unikernel

We could leverage the Rust VMM libraries (the ones used by firecraker and crosvm) to build it, use cloud-hypervisor or other things you have in mind. It would be great to have all of that written in Rust, because it would allow me to reuse other Wasm/OCI-related things I'm already using inside of other projects I maintain/contribute to.

First step

Have a cli program that works in this way:

console run

This would setup the network stack and run the unikernel image provided by the cli.

In this case we don't care about the unikernel being run. It could be the "hello world" example from hermit or it could be the wasm unikernel I'm building. In the latter case, the unikernel image would also bundle inside of itself the actual WebAssembly module.

Second step

Have a cli program that works in this way:

console run

The binary will now bundle the wasm unikernel application, hence it's no longer required to specify that on the cli. Instead, on the cli the user will point us to the WebAssembly module to run. The module will somehow be injected into the VM and consumed by the unikernel. How to do that, I have some ideas, but you're the virtualization expert, I rely on you to help me with that add-emoji .

This makes the unikernel image generic, because there's no need to bundle the actual WebAssembly module to execute inside of it.

Resources

I've still to upload the POC on GitHub. In the meantime these are the Virtualization related links:

Join this project

Looking for hackers with the skills:

virtualization rust

This project is part of:

Hack Week 22

Activity

  • almost 3 years ago: paulgonin liked this project.
  • almost 3 years ago: ademicev0 liked this project.
  • almost 3 years ago: moio liked this project.
  • almost 3 years ago: rcase liked this project.
  • almost 3 years ago: mberti liked this project.
  • almost 3 years ago: flavio_castelli started this project.
  • almost 3 years ago: flavio_castelli added keyword "virtualization" to this project.
  • almost 3 years ago: flavio_castelli added keyword "rust" to this project.
  • almost 3 years ago: flavio_castelli originated this project.


    • Comments

    • flavio_castelli
      almost 3 years ago by flavio_castelli | Reply

      Project update

      I started writing a series of blog post about this project. You can find the first one here.

      I got a POC working, I managed to achieve the "main" goal, but I didn't have time/help to accomplish the secondary virtualization goals.

      You can find the working prototype here

    Similar Projects

    Extracting, converting and importing VMs from Nutanix into SUSE Virtualization by emendonca

    Description

    The idea is to delve into understanding Nutanix AHV internals on how it stores and runs VMs, and how to extract them in an automated way for importing into a KVM-compatible hypervisor, like SUSE Virtualization/Harvester. The final product will be not only be documentation, but a working prototype that can be used to automate the process.

    Goals

    1) document how to create a simple lab with NutaniX AHV community edition 2) determine the basic elements we need to interact with 3) determine what are the best paths to grab the images through, balancing speed and complexity 4) document possible issues and create a roadmap for tackling them 4) should we adapt an existing solution or implement a new one? 5) implement the solution!

    Resources

    Similar project I created: https://github.com/doccaz/vm-import-ui Nutanix AHV forums Nutanix technical bulletins

    SUSE KVM Best Practices - Focus on SAP Workloads and Use Cases by roseswe

    Description

    SUSE Best Practices around KVM, especially for SAP workloads. Early Google presentation already made from various customer projects and SUSE sources.

    Goals

    • Complete presentation we can reuse in SUSE Consulting projects
    • 2025: Bring it to version 1.00 ready for customers

    Resources

    KVM (virt-manager) images

    SUSE/SAP/KVM Best Practices

    • https://documentation.suse.com/en-us/sles/15-SP6/single-html/SLES-virtualization/
    • SAP Note 1522993 - "Linux: SAP on SUSE KVM - Kernel-based Virtual Machine" && 2284516 - SAP HANA virtualized on SUSE Linux Enterprise hypervisors https://me.sap.com/notes/2284516
    • SUSECon24: [TUTORIAL-1253] Virtualizing SAP workloads with SUSE KVM || https://youtu.be/PTkpRVpX2PM
    • SUSE Best Practices for SAP HANA on KVM - https://documentation.suse.com/sbp/sap-15/html/SBP-SLES4SAP-HANAonKVM-SLES15SP4/index.html

    Contribute to terraform-provider-libvirt by pinvernizzi

    Description

    The SUSE Manager (SUMA) teams' main tool for infrastructure automation, Sumaform, largely relies on terraform-provider-libvirt. That provider is also widely used by other teams, both inside and outside SUSE.

    It would be good to help the maintainers of this project and give back to the community around it, after all the amazing work that has been already done.

    If you're interested in any of infrastructure automation, Terraform, virtualization, tooling development, Go (...) it is also a good chance to learn a bit about them all by putting your hands on an interesting, real-use-case and complex project.

    Goals

    • Get more familiar with Terraform provider development and libvirt bindings in Go
    • Solve some issues and/or implement some features
    • Get in touch with the community around the project

    Resources

    Q2Boot - A handy QEMU VM launcher by amanzini

    Description

    Q2Boot (Qemu Quick Boot) is a command-line tool that wraps QEMU to provide a streamlined experience for launching virtual machines. It automatically configures common settings like KVM acceleration, virtio drivers, and networking while allowing customization through both configuration files and command-line options.

    The project originally was a personal utility in D, now recently rewritten in idiomatic Go. It lives at repository https://github.com/ilmanzo/q2boot

    Goals

    Improve the project, testing with different scenarios , address issues and propose new features. It will benefit of some basic integration testing by providing small sample disk images.

    Updates

    • Dec 1, 2025 : refactor command line options, added structured logging. Released v0.0.2
    • Dec 2, 2025 : added external monitor via telnet option
    • Dec 4, 2025 : released v0.0.3 with architecture auto-detection
    • Dec 5, 2025 : filing new issues and general polishment. Designing E2E testing

    Resources

    SUSE Virtualization (Harvester): VM Import UI flow by wombelix

    Description

    SUSE Virtualization (Harvester) has a vm-import-controller that allows migrating VMs from VMware and OpenStack, but users need to write manifest files and apply them with kubectl to use it. This project is about adding the missing UI pieces to the harvester-ui-extension, making VM Imports accessible without requiring Kubernetes and YAML knowledge.

    VMware and OpenStack admins aren't automatically familiar with Kubernetes and YAML. Implementing the UI part for the VM Import feature makes it easier to use and more accessible. The Harvester Enhancement Proposal (HEP) VM Migration controller included a UI flow implementation in its scope. Issue #2274 received multiple comments that an UI integration would be a nice addition, and issue #4663 was created to request the implementation but eventually stalled.

    Right now users need to manually create either VmwareSource or OpenstackSource resources, then write VirtualMachineImport manifests with network mappings and all the other configuration options. Users should be able to do that and track import status through the UI without writing YAML.

    Work during the Hack Week will be done in this fork in a branch called suse-hack-week-25, making progress publicly visible and open for contributions. When everything works out and the branch is in good shape, it will be submitted as a pull request to harvester-ui-extension to get it included in the next Harvester release.

    Testing will focus on VMware since that's what is available in the lab environment (SUSE Virtualization 1.6 single-node cluster, ESXi 8.0 standalone host). Given that this is about UI and surfacing what the vm-import-controller handles, the implementation should work for OpenStack imports as well.

    This project is also a personal challenge to learn vue.js and get familiar with Rancher Extensions development, since harvester-ui-extension is built on that framework.

    Goals

    • Learn Vue.js and Rancher Extensions fundamentals required to finish the project
    • Read and learn from other Rancher UI Extensions code, especially understanding the harvester-ui-extension code base
    • Understand what the vm-import-controller and its CRDs require, identify ready to use components in the Rancher UI Extension API that can be leveraged
    • Implement UI logic for creating and managing VmwareSource / OpenstackSource and VirtualMachineImport resources with all relevant configuration options and credentials
    • Implemnt UI elements to display VirtualMachineImport status and errors

    Resources

    HEP and related discussion

    SUSE Virtualization VM Import Documentation

    Rancher Extensions Documentation

    Rancher UI Plugin Examples

    Vue Router Essentials

    Vue Router API

    Vuex Documentation

    Looking at Rust if it could be an interesting programming language by jsmeix

    Get some basic understanding of Rust security related features from a general point of view.

    This Hack Week project is not to learn Rust to become a Rust programmer. This might happen later but it is not the goal of this Hack Week project.

    The goal of this Hack Week project is to evaluate if Rust could be an interesting programming language.

    An interesting programming language must make it easier to write code that is correct and stays correct when over time others maintain and enhance it than the opposite.

    Mail client with mailing list workflow support in Rust by acervesato

    Description

    To create a mail user interface using Rust programming language, supporting mailing list patches workflow. I know, aerc is already there, but I would like to create something simpler, without integrated protocols. Just a plain user interface that is using some crates to read and create emails which are fetched and sent via external tools.

    I already know Rust, but not the async support, which is needed in this case in order to handle events inside the mail folder and to send notifications.

    Goals

    • simple user interface in the style of aerc, with some vim keybindings for motions and search
    • automatic run of external tools (like mbsync) for checking emails
    • automatic run commands for notifications
    • apply patch set from ML
    • tree-sitter support with styles

    Resources

    • ratatui: user interface (https://ratatui.rs/)
    • notify: folder watcher (https://docs.rs/notify/latest/notify/)
    • mail-parser: parser for emails (https://crates.io/crates/mail-parser)
    • mail-builder: create emails in proper format (https://docs.rs/mail-builder/latest/mail_builder/)
    • gitpatch: ML support (https://crates.io/crates/gitpatch)
    • tree-sitter-rust: support for mail format (https://crates.io/crates/tree-sitter)

    Learn a bit of embedded programming with Rust in a micro:bit v2 by aplanas

    Description

    micro:bit is a small single board computer with a ARM Cortex-M4 with the FPU extension, with a very constrain amount of memory and a bunch of sensors and leds.

    The board is very well documented, with schematics and code for all the features available, so is an excellent platform for learning embedded programming.

    Rust is a system programming language that can generate ARM code, and has crates (libraries) to access the micro:bit hardware. There is plenty documentation about how to make small programs that will run in the micro:bit.

    Goals

    Start learning about embedded programming in Rust, and maybe make some code to the small KS4036F Robot car from keyestudio.

    Resources

    Diary

    Day 1

    • Start reading https://mb2.implrust.com/abstraction-layers.html
    • Prepare the dev environment (cross compiler, probe-rs)
    • Flash first code in the board (blinky led)
    • Checking differences between BSP and HAL
    • Compile and install a more complex example, with stack protection
    • Reading about the simplicity of xtask, as alias for workspace execution
    • Reading the CPP code of the official micro:bit libraries. They have a font!

    Day 2

    • There are multiple BSP for the microbit. One is using async code for non-blocking operations
    • Download and study a bit the API for microbit-v2, the nRF official crate
    • Take a look of the KS4036F programming, seems that the communication is multiplexed via I2C
    • The motor speed can be selected via PWM (pulse with modulation): power it longer (high frequency), and it will increase the speed
    • Scrolling some text
    • Debug by printing! defmt is a crate that can be used with probe-rs to emit logs
    • Start reading input from the board: buttons
    • The logo can be touched and detected as a floating point value

    Day 3

    • A bit confused how to read the float value from a pin

    OpenPlatform Self-Service Portal by tmuntan1

    Description

    In SUSE IT, we developed an internal developer platform for our engineers using SUSE technologies such as RKE2, SUSE Virtualization, and Rancher. While it works well for our existing users, the onboarding process could be better.

    To improve our customer experience, I would like to build a self-service portal to make it easy for people to accomplish common actions. To get started, I would have the portal create Jira SD tickets for our customers to have better information in our tickets, but eventually I want to add automation to reduce our workload.

    Goals

    • Build a frontend website (Angular) that helps customers create Jira SD tickets.
    • Build a backend (Rust with Axum) for the backend, which would do all the hard work for the frontend.

    Resources

    RMT.rs: High-Performance Registration Path for RMT using Rust by gbasso

    Description

    The SUSE Repository Mirroring Tool (RMT) is a critical component for managing software updates and subscriptions, especially for our Public Cloud Team (PCT). In a cloud environment, hundreds or even thousands of new SUSE instances (VPS/EC2) can be provisioned simultaneously. Each new instance attempts to register against an RMT server, creating a "thundering herd" scenario.

    We have observed that the current RMT server, written in Ruby, faces performance issues under this high-concurrency registration load. This can lead to request overhead, slow registration times, and outright registration failures, delaying the readiness of new cloud instances.

    This Hackweek project aims to explore a solution by re-implementing the performance-critical registration path in Rust. The goal is to leverage Rust's high performance, memory safety, and first-class concurrency handling to create an alternative registration endpoint that is fast, reliable, and can gracefully manage massive, simultaneous request spikes.

    The new Rust module will be integrated into the existing RMT Ruby application, allowing us to directly compare the performance of both implementations.

    Goals

    The primary objective is to build and benchmark a high-performance Rust-based alternative for the RMT server registration endpoint.

    Key goals for the week:

    1. Analyze & Identify: Dive into the SUSE/rmt Ruby codebase to identify and map out the exact critical path for server registration (e.g., controllers, services, database interactions).
    2. Develop in Rust: Implement a functionally equivalent version of this registration logic in Rust.
    3. Integrate: Explore and implement a method for Ruby/Rust integration to "hot-wire" the new Rust module into the RMT application. This may involve using FFI, or libraries like rb-sys or magnus.
    4. Benchmark: Create a benchmarking script (e.g., using k6, ab, or a custom tool) that simulates the high-concurrency registration load from thousands of clients.
    5. Compare & Present: Conduct a comparative performance analysis (requests per second, latency, success/error rates, CPU/memory usage) between the original Ruby path and the new Rust path. The deliverable will be this data and a summary of the findings.

    Resources

    • RMT Source Code (Ruby):
      • https://github.com/SUSE/rmt
    • RMT Documentation:
      • https://documentation.suse.com/sles/15-SP7/html/SLES-all/book-rmt.html
    • Tooling & Stacks:
      • RMT/Ruby development environment (for running the base RMT)
      • Rust development environment (rustup, cargo)
    • Potential Integration Libraries:
      • rb-sys: https://github.com/oxidize-rb/rb-sys
      • Magnus: https://github.com/matsadler/magnus
    • Benchmarking Tools:
      • k6 (https://k6.io/)
      • ab (ApacheBench)