My First Unikernel
roscidus.com
My First Unikernel
1–10 of 53 posts
Re: My First Unikernel
#2See also this discussion of MirageOS from 2.5 months ago:
Re: My First Unikernel
#3I'm a little confused about the direction things are going in. I like high level languages and I like that the OS manages certain resources so I don't have to. This guy is writing directly to block devices from OCaml. Don't get me wrong it's all pretty cool but there is some kind of dissonance there I can't reconcile. Is Xen the new OS now?
Re: My First Unikernel
#4I'm a little confused about the direction things are going in. I like high level languages and I like that the OS manages certain resources so I don't have to. This guy is writing directly to block devices from OCaml. Don't get me wrong it's all pretty cool but there is some kind of dissonance there I can't reconcile. Is Xen the new OS now?
Yes, basically. You let the host manage memory, disk, network etc and your program is a guest OS that doesn't need all the extraneous processes that usually go with a whole OS. No background services or cron jobs.
Edit: as enduser pointed out, in addition to saving resources, this means there is no context-switching from kernelspace to userspace in your guest VM!
Re: My First Unikernel
#5If it helps to add clarity to what this is about, Xen still requires a host (dom0) operating system, usually Linux but also NetBSD and OpenSolaris. Mirage OS (the basis for building your own unikernel) allows building applications as domU kernels. This is advantageous because it minimizes context-switching and allows all of the code in a Xen VM (domU) to be written in a safer language than C.
So the dom0 OS (Linux) still determines which devices are exposed to the Unikernel. The Unikernel implementation is simple relative to a full "bare metal" OS because it only needs to support the Xen interfaces to block devices, the network, etc., and does not have to deal with disk drives, ethernet controllers, etc.
If you are running your own hardware, you're probably better off using something like FreeBSD + Jails or Linux + LXC (Docker). The Unikernel approach is more appropriate for situations where you want to deploy applications on Xen-based cloud infrastructure (Amazon EC2, Rackspace Cloud Servers) and do not want to waste resources or increase security risk by running a full OS. The physical servers at Amazon and Rackspace are already running a full dom0 OS (probably Linux), so running another full OS on top of that just to run your app is inefficient.
Re: My First Unikernel
#6This sounds like an awesome and fun project to hack on!
However, optimizing around context switches and task preemptions is something you would usually do if your application is actually bound by IO/context switching, is extremely latency sensitive or when you are trying to squeeze the last bits of performance out of a machine. Why did you choose to build such a microoptimized system in a garbage collected language? Doesn't this defeat the purpose of the whole exercise?
I feel the need for more powerful types and built-in/standardized exception handling too, but since performance seems to be one of your major goals, wouldn't something like C++ be a better fit here? You'd get proper error handling and a good type system (with some tradeoffs) without a significant performance penalty.
On a sidenote, I agree that code written in a functional language with a strong type system tends to be easier to get right than bare C, but this doesn't imply that all low-level code is bug ridden and unsafe. In fact the linux kernel is one of the most stable and reliable pieces of software I've had the pleasure to work with so far. Suggesting there is a problem with the linux kernel because it contains "a large amount of C code in security-critical places" seems a bit dishonest.
Re: My First Unikernel
#7So I have been following this stuff with a lot of interest, but I am not very familiar with Ocaml and have tried looking at Mirage docs with some limited downtime.
If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? Does this mean Mirage unikernels handle only one processor/core in Amazon and elsewhere?
Re: My First Unikernel
#8I'm a little confused about the direction things are going in. I like high level languages and I like that the OS manages certain resources so I don't have to. This guy is writing directly to block devices from OCaml. Don't get me wrong it's all pretty cool but there is some kind of dissonance there I can't reconcile. Is Xen the new OS now?
> This guy is writing directly to block devices from OCaml. Don't get me wrong it's all pretty cool but there is some kind of dissonance there I can't reconcile. Is Xen the new OS now?
For some applications removing this overhead might be interesting - e.g. databases tend to fight with the peculiarities in the host OS (scheduler, caching, disk access patterns).
The major upside of this approach IMO is the added robustness you get, since deploying turns into a very deterministic procedure, there's no underlying OS updates and whatnot to break your app.
Re: My First Unikernel
#9So I have been following this stuff with a lot of interest, but I am not very familiar with Ocaml and have tried looking at Mirage docs with some limited downtime. If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? Does this mean Mirage unikernels handle only one processor/core in Amazon and elsewhere?
> If Ocaml can only handle one core and does not do SMP, how does it do in the cloud?
+1 to this question? Any one experienced enough in OCaml to answer this?
Re: My First Unikernel
#10So I have been following this stuff with a lot of interest, but I am not very familiar with Ocaml and have tried looking at Mirage docs with some limited downtime. If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? Does this mean Mirage unikernels handle only one processor/core in Amazon and elsewhere?
> If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? +1 to this question? Any one experienced enough in OCaml to answer this?
One could argue that threading is not strictly necessary to utilize a multicore machine. A lot of applications (think web apps) can be implemented just fine as a single thread and then scaled up by increasing the number of processes (or the number of virtual machines in this case) rather than the number of threads.
A lot of popular web frameworks follow this paradigm and I would guess that most application code running "in the cloud" is in fact single threaded.