
UKL: A Unikernel Based on Linux - perbu
https://next.redhat.com/2018/11/14/ukl-a-unikernel-based-on-linux/
======
zippie
This is great progress towards making unikernels non-runtime specific.

However, I am still skeptical of the idea that unikernels will ever be
production friendly. The biggest deficiency, by the definition of a unikernel,
is the complete lack of debugging tools available. There is no top, perf, etc
in a unikernel. In docker, I can still exec into a running container to debug
and investigate. Unikernel issues lend themselves to “just restart it” rather
than “let’s debug and fix it” mindsets.

I’ve run a k8s environment with kata containers for a while and as time has
gone on, I’ve found that Solaris Zones (smartOS) are probably the most
scalable way to achieve process/VM isolation for applications.

~~~
eyberg
htop and such don't make sense inside a single process system; logging usually
gets sent to remote syslog/elk/etc. many apm solutions work out of the box

one of the biggest misconceptions about unikernels is that they are somehow of
a slimmed down linux - it's easier to think about them as individual programs
provisioned as vms - would you ssh into a process? why?

all 'debugging' tools work perfectly fine w/unikernels although I'd draw a
fine line between real application level debugging which should never happen
on production and ops tooling

~~~
rjzzleep
> I'd draw a fine line between real application level debugging which should
> never happen on production and ops tooling

Sorry, but that's just plain wrong. One very common reason why people do that
is, because performance debugging may give very different results on dev,
staging and production systems that's why people want tooling that gives them
as accurate as possible application level debugging information without
impeding the behavior of the system. It's a very common problem in large scale
systems.

~~~
int0x80
I think that can be solved by good tracing and logging facilities. Both of
which are already available in Linux (eBPF, ftrace, tracepoints, perf
events...). You may have to customize them or polish them further though and
provide more user friendly interfaces/frontends for them.

~~~
paulddraper
Though the amount of tracing/logging to equate to debugging is so much that
you will want to turn it on selectively.

And you will want a mechanism to iterate quickly to see effects of tweaks.

Eventually you have built an interactive debugger.

~~~
int0x80
Maybe. But KGDB and friends do exist too in Linux. And (AFAIK) not everyone
likes using those, some just like throwing a few printks here and there. That
is not universal obviously :) My point is that yes, unikernels may not be as
easy to debug etc at this point as regular usermode code, but it is something
that can be worked around and I think if people begin to use them in-mass
frameworks and solutions will emerge.

~~~
paulddraper
Yes. It is a deficiency/roadblock to adoption.

One that could improve.

------
seliopou
Link to GitHub repo:

    
    
        https://github.com/razaaliraza/ukl
    

The article itself should have linked to it. It's a bad look to announce a
project and only link to a bunch of other "competing" projects. Makes it looks
like vaporware, but apparently there is code out there.

~~~
joppy
Why post a link which is not clickable?

------
anonymousDan
How does this differ from LKL (the Linux kernel library :
[https://github.com/lkl/linux](https://github.com/lkl/linux) )?

~~~
pickdenis
A simple scan of the repo's description and the first sentence of the linked
article should answer that question. LKL is a library that allows you to do
Linux things (read/write linux filesystems) from outside of Linux, essentially
re-using the kernel's code. UKL, is an unikernel which essentially allows you
to compile an application into a standalone OS that runs it (not sure if
that's entirely correct).

Now that I think about it a little more, they're kind of similar but I think
unikernels are more of a way to get an application to run on hardware without
all the extra bloat of a monolithic kernel (like if you're running a web
service on a small virtualized machine) and the LKL is just for re-using Linux
code.

------
erichocean
Seeing as how you can already run normal Linux like a unikernel on N-1 cores,
and get all of the debugging and management goodness on core 0, I don't see
the point. At all.

~~~
eyberg
the big idea is that _most_ companies are heavily virtualized - if you are
using aws/gce you most definitely are and many private datacenters are as well
- I'm not going to speak for ukl in particular but in general unikernels are
vastly more secure than a normal process and much faster (if you are already
virtualized which you are on aws/gce) - there is absolutely no reason to have
2 layers of linux if you are in 'the cloud'

~~~
geggam
Except the fact most production level code has support from the OS running
scripts or some other hack to keep the code running.

I have yet to see a production stack without this.

------
tinktank
How is this different from UML?

~~~
glibgil
No one knows what that is

~~~
dtzWill
[https://en.wikipedia.org/wiki/User-
mode_Linux](https://en.wikipedia.org/wiki/User-mode_Linux)

~~~
stcredzero
UML used to refer to an entity/relationship+methods modeling language.

[https://en.wikipedia.org/wiki/Unified_Modeling_Language](https://en.wikipedia.org/wiki/Unified_Modeling_Language)

~~~
andrewstuart
Thank goodness we hear almost nothing about UML any more.

~~~
pjmlp
Just last week someone on our project was drawing a sequence diagram for an
interaction between lambda calls on a cloud provider.

UML is pretty much in use on the enterprise space.

------
hossbeast
This is really exciting. Great write-up, and I'll be following with interest.

------
elihu
That seems like it could be an interesting way to launch Rust applications.
Typically (and I'm assuming UKL is no different), unikernels don't have any
memory protection between applications and the OS. That's usually a bad thing;
however, if your compiler can verify that memory accesses are all in-bounds,
then all the hardware memory checks that an MMU would do in a regular OS are
just unnecessary overhead. So, with UKL and a Rust application, you could get
approximately the same level of safety as before, but without the performance
cost of all that runtime memory protection. Entering the kernel can be just a
regular function call, context switches are cheap, etc... That could be a huge
performance boon for some apps.

In this sort of setup, unsafe Rust is like kernel code -- it effectively has
privilege to read/write to any memory.

I'd also feel better if the kernel itself were written in something like Rust.

~~~
eyberg
all unikernel implementations I'm familiar with are single process by nature
and thus the protection that you need on a multiple process system such as
linux is completely un-necessary, especially since they are always deployed as
vms

~~~
elihu
Well, strictly speaking it's safer to have a system where the application
can't write into kernel memory space and the kernel can't (accidentally) write
into application space.

You don't have the risk of leaking secrets or malicious interference between
applications that are supposed to be isolated if you've only got one app, but
I could still see where someone might rather have memory protection than not
in a single-user/single-application environment.

