Unikernel Devel

HaLVM v3: The Plan


The full document: http://uhsure.com/halvm3.html

This document is designed to familiarize readers with the history of the HaLVM, and then use that history to point towards where we want to go with HaLVM v3.

Got questions? Post them here. You’ll note a distinct lack of comments section on the site above; why not post comments here?


Greate writeup! After having messed around with haskell for a while ive now decided that this is the project i want to start contributing to both because i like the idea and because i see it as an opportunity to go further into the dark caves of haskell.

Now, a few things ive been thinking about:

There is currently no issues tagged with v3.0 and most of the issues are pretty old. As someone who wants to contribute, a great motivation would be having new and updated issues to start playing with.

As far as i understand there is no other communication channel other than the mailing list. I find it really useful to have something like slack/irc while working on a project. If there is interest for this, im willing to set it up myself.

Looking forward to starting, hoping i wont become yet another crushed soul :slight_smile:


Ack! I knew there was something else I was supposed to do before I published that.

I will try to start flooding the issue tracker with ideas today or tomorrow, and will post back when I think I’m done. Thanks for pointing that out, and I look forward to any help you can provide.

As for Slack, there probably should be a Slack channel. I’m not sure how good I’m going to be with it; we don’t use Slack here at work, and I already get interrupted quite a lot. But I’ll promise to look in every once in awhile if you make the channel.


Re Slack: given we’re moving under the unikernel.org umbrella for the mailing list anyway, might it be worth seeing if they have one & just get a channel? bit of cross-pollination etc.


I like this idea. Any idea who to ask if one already exists?


maybe @amirmc might know? not sure.


Hi @yemi, @mwotton!

I’m hoping we can use this forum instead of setting up Slack. Slack won’t keep any history beyond 10k messages (we’d hit that quicker than you realise), and we’d lose those access to those messages over time. It’s also difficult for anyone who doesn’t sign up to see what’s going on so we end up creating a closed silo of discussions. I think we should try to avoid that if possible.

I’d be curious to know if the current forum could fit your needs, as it can operate somewhere in between a mailing list and message client (depending on how you configure your settings).

Of course, if people feel that Slack would be really important/useful then we can look into it.




I have been following HaLVM for a while, but haven’t created any unikernels worth talking about.

One thought i had, You talk about shifting to other platforms(Unikernel Base), ie RumpRun and Solo5, for development purposes do you think a POXIS Unikernel Base would help with HaLVM development?

Which made me think, wouldn’t HaLVM have a API, as such, that it expects? and for a Unikernel Base to work with HalVM it would need to supply this API? which I think ties back into your HaLVMInterfaces and The New Library Regime vision.

I would love to help is some regard but i just don’t know where to start?

Just my thoughts


Hi Adam,

I work with both the rump kernel/rumprun unikernel stack and Solo5. As part of my work at Unikernel Systems (now Docker) I ported Mirage to run on rumprun and, together with Dan Williams @ IBM, am currently completing a Mirage/Solo5 port.

A few points that may help you to decide on which direction(s) to take for HalVM:

You are correct in your analysis that rumprun provides more functionality, including drivers to run directly on bare metal without a hypervisor. However, this comes with a size cost (a couple of megabytes) and a complexity cost in integration, especially with regard to integrating the rump kernel network interface drivers with a non-rump-kernel TCP stack (which I presume you would want to do for HalVM).

Regarding Solo5, it is much simpler, but also does much less. Some of this is due to the code still being very young and evolving, some is by design. The idea with Solo5 is to provide a minimal base needed to run unikernels such as Mirage on top of virtio-based hypervisors and also the experimental ukvm hypervisor that the team at IBM research is working on.

A notable consequence of this is that unlike rumprun, Solo5 does not attempt to provide a POSIX environment or full libc, neither does it provide a scheduler (since Mirage already has its own). Also, Solo5 is not aiming to target bare metal (i.e. run without a hypervisor). The benefit of this is reduced complexity and a much smaller codebase (~110kB for the virtio target).

You can take a look at the minimalist C glue layer reqiured to run the OCaml runtime on Solo5 at https://github.com/mato/ocaml-freestanding, and the work in progress Solo5 platform bindings for Mirage at https://github.com/djwillia/mirage-platform/tree/solo5.

I’d be interested to know exactly which interfaces you need from the base layer to run the HaLVM. It may be possible to add this functionality to Solo5 or build a glue layer analogous to ocaml-freestanding for HalVM.

Hope this helps,



Hi Martin -

Yeah, I knew I should email you about your experience with both.

It’s good to know that my assumptions about both seem to match your experience, although I’ll admit that I’d hoped one would be a magical solution that would solve all my problems. We’ll have to poke around on both sides to see which works out in the end.

As for your direct question, the HaLVM itself requires very little in terms of its operating environment. We could certainly host it on Solo5 without much of a problem, and probably not with much work. The challenge is actually Haskell libraries, many of which reach out into POSIX-land for various reasons, either intentionally or unintentionally. So this is more about adoption than about technology. Right now, when people ask if a library will work on the HaLVM, I have to hem and haw about stuff. If I had POSIX around me, I could say “probably” :slight_smile:. Even though, honestly, I’d prefer people use a different, less-POSIX solution.

Do you have any intuition about how hard it would be to host uClibc (or something like that) on top of Solo5?

  • Adam


Hi Adam,

With Mirage/Solo5 I’m deliberately going down the route of eliminating dependencies on C/POSIX libraries as much as possible – is this not an option for those Haskell libraries which people might want to use with HaLVM?

Regarding hosting a libc on Solo5, it depends on how much of a libc you need:

  • Providing “standard C runtime” interfaces (e.g. stdlib.h) is not a problem. I’d go and pick the needed bits from musl, much as I’ve done in ocaml-freestanding.
  • Providing POSIX system interfaces (e.g. sockets, poll, threads, …) will not work as Solo5 does not have functionality to implement these. If you must go down this route I’d go with rumprun and the NetBSD libc.

I will also point out that the rumprun/NetBSD libc combination is valuable as you’re essentially getting unmodified, production-quality and proven code from NetBSD maintenance-free. Porting existing POSIX/C code to run on it is fairly easy as long as the code does not assume that “all the world’s Linux”.



In the long term, and as a general strategy, I’d like to push the Haskell
community away from their deep dependence on POSIX, and get people to
modify their libraries and programs to be able to work with the HaLVM.

The more practical truth, though, is that I’m caught in an awkward catch-22
in which I can’t get authors of some key libraries to change their systems
unless I have a large and noisy user base, and I can’t get a large and
noisy user base unless these key libraries can be used on the HaLVM. So
thus the need to get me enough POSIX to start kickstarting the process of
fighting against POSIX. :slight_smile:

  • Adam