Atmanos: Build Go programs that run directly on the Xen hypervisor
github.com
github.com
From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.
So who cares? What else is HN for if not for posting cool hacks and projects and encouraging fellow builders?
From my read, it counters Bryan Cantrill's claim that, "unikernels are undebuggable".
From personal experience I'm also quite certain Bryan Cantrill's claim is spurious in that regard, as I've used both debugging and tracing facilities w/ LING unikernels to assess a number of runtime and clustering issues.
That is how we used to program many 8 and 16 bit applications, and how many keep programming embedded systems nowadays.
By having a rich runtime (kernel) that exposes the internals to the world, like Mission Control, TraceViewer and the respective debuggers, when the right set of flags/authentication are enabled.
Unikernel are no different from running embedded applications, bare metal.
Unikernels on the other hand, do actually run on vehicles. There are a few embedded runtimes based on the same architecture.
They have debugging support to attach to graphical debugger, probes, JTAGs, and a few other vendor specific tools.
Of course someone trying to sell me Solaris/Illumnos, will have prejudice to anything else.
Inside of a vehicle, not yet; production example, yes.
Back in the day, there was a kernel bug which prevented Solaris 10 installer from booting on systems with a Pentium III processor. The workaround was to boot the kernel with -k, let it crash and drop into kdb, then patch a certain kernel structure and drop out of the debugger, continuing execution. The same mechanism would work in a car or a Boeing 787, which I understand were actually running Solaris as the control & navigation system.
Interesting. I'd like to see a return to owning/renting whole machines and running containers on them directly (as several major tech companies do). A lot of the value proposition for the cloud service providers is a multi-host hypervisor that's really easy to get started with (compared to buying vSphere). If it becomes really easy to deploy your own instance of an open-source container scheduler across your own boxes, we can return to cost-competitive commodity boxes instead of overpaying for AWS.
For SMB private clouds, its a no-brainer; I just buy a FreeNAS or TrueNAS box (FreeBSD based) from iXSystems and have them customize the box for extra ram and CPU. You get ZFS, DTrace and a wicked NAS, OS level virtualization with jails and even linux binary support if required. I've done this successfully in production and could not be happier.
Note: I don't work for iXSystems but I do love their products and services.
Same here, especially since the zones that the Joyent containers are built on are really easy to use and provide entire miniature yet full fledged UNIX servers, not to mention it’s all open source and gratis and the community is really competent.
Then again, this brings us to the same issues that the *BSD and Darwin kernels have, with really lackluster driver availability. While some big corps like Sony might get AMD to build them a performant GPU driver, the tragedy of the commons situation repeatedly occurs with BSD licensed projects, major improvements aren't contributed upstream reliably as there is no business reason.
Not trying to be stupid, but I'm not really clear on what the advantage is of this system. Do I understand correctly that the dom0 OS is still providing drivers and hardware abstraction? So both that and some userland exists somewhere in the stack; it's just not duplicated in the virtualized OSes?
Is the main goal simplicity, performance, or something else?
And yes, I see some value in the reduction of maintenance costs, but you're not doing this manually--you have a package manager of some sort and you're automatically tracking some standard image (either for your company or from some upstream maintainer like Canonical). So conceptually I get the simplicity argument, but practically speaking, it's not really more work to maintain two userlands vs one, right?
I guess there's also an argument of resource (disk, memory footprint, etc) overhead of the second userland. It's not clear to me how significant that is, which was part of my question.
Generally if you are going to use something like this or MirageOS you will choose to pass through certain real hardware to the guest and write drivers for it.
Say for instance pass through an Intel NIC and then have your application embed a TCP stack and DPDK like components so that you can run your application at line rate.
Aside from performance, what are the alleged benefits of a unikernel? Security?
Unikernels just remove a whole security layer. May as well run the app as a user process on the host and forget the VM.
Perhaps I should have phrased that differently, but you've reduced the attack surface for compromising your _app_ via the environment (instead of the environment via your app).
(big disclaimer: this is assuming Xen bugs are much more valuable than app bugs and someone with a Xen exploit won't be focusing on you.)
App exploit (-> LSM breakout?) -> local to root escalation -> VM to host escalation via device.
For a unikernel deployment that's just:
App exploit -> VM to host via device.
It does move the hypervisor up a few levels of abstraction, which could be dangerous, but (more to the point) the benefit is isolation from other misbehaving apps.
Other wise - just have a slimmed down OS with ACLs.
Is anyone running JVM on a slim OS? http://unikernel.org/projects/ seems to have quite a list OSv ? mirageOS?
That project aims to reduce the effort for porting applications to run in unikernels on different platforms (Xen, KVM and baremetal).
https://lists.xen.org/archives/html/xen-devel/2017-09/msg036...
What exactly happens with SMP with this sort of application?
I'd have to read a compelling technical explanation before believing this could perform better than a Linux or BSD kernel.
In most cases, the Go code is going to be single CPU, and that ain't the way the world works anymore. There's going to be a bunch of wasted computing power on that VM
Instead of sharing the code at runtime, i.e. what an OS does. You could easily share code at compile time, i.e. statically link a library.
Because of sharable code, "implementing * in application" should always be at-least as performant as the best generic implementation (i.e. the implementation you find in a general purpose OS). However, when appropriate, customizing the implementation for the application would allow it to become even more performant.
So it's not just that this has to perform better than a kernel, it has to perform better than not involving the kernel in the critical path, and it has to perform so much better that it's worth wanting to beat yourself in the face with a hammer after trying to diagnose the latest lockup. Unikernels are interesting to me, but like the demoscene or a semi tractor doing wheelies. Not for production usage.