Atmanos: Build Go programs that run directly on the Xen hypervisor
1–10 of 56 posts
Re: Atmanos: Build Go programs that run directly on the Xen hypervisor
#2This is quite interesting, are there major performance benefits to using something like AtmanOS? My main concern is if something like this will ever be able to run bare metal, and cut out the overhead of a hypervisor, if performance is critical, then a dedicated box is likely.
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.
Re: Atmanos: Build Go programs that run directly on the Xen hypervisor
#3This is quite interesting, are there major performance benefits to using something like AtmanOS? My main concern is if something like this will ever be able to run bare metal, and cut out the overhead of a hypervisor, if performance is critical, then a dedicated box is likely. Then again, this brings us to the same issues that the *BSD and Darwin kernels have, with really lackluster driver availability. While some bi…
Well performance aside there is also the benefit of not having to maintaining userland.
Re: Atmanos: Build Go programs that run directly on the Xen hypervisor
#4This is quite interesting, are there major performance benefits to using something like AtmanOS? My main concern is if something like this will ever be able to run bare metal, and cut out the overhead of a hypervisor, if performance is critical, then a dedicated box is likely. Then again, this brings us to the same issues that the *BSD and Darwin kernels have, with really lackluster driver availability. While some bi…
That is why you use Xen as a base. Xen lets the dom0 (primary domain) handle the device drivers and then provides guests access to them via paravirtualised interfaces. I.e you get Linux compatibility and then you can run any OS that has paravirtualised drivers written for it.
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.
Re: Atmanos: Build Go programs that run directly on the Xen hypervisor
#5This is quite interesting, are there major performance benefits to using something like AtmanOS? My main concern is if something like this will ever be able to run bare metal, and cut out the overhead of a hypervisor, if performance is critical, then a dedicated box is likely. Then again, this brings us to the same issues that the *BSD and Darwin kernels have, with really lackluster driver availability. While some bi…
Well performance aside there is also the benefit of not having to maintaining userland.
What are the overheads of maintaining userland?
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?
Re: Atmanos: Build Go programs that run directly on the Xen hypervisor
#6I’d be interested to see performance comaprisons between this and Go on a Linux variant.
Aside from performance, what are the alleged benefits of a unikernel? Security?
Re: Atmanos: Build Go programs that run directly on the Xen hypervisor
#7I’d be interested to see performance comaprisons between this and Go on a Linux variant. Aside from performance, what are the alleged benefits of a unikernel? Security?
Much smaller attack surface.
Re: Atmanos: Build Go programs that run directly on the Xen hypervisor
#8Earlier quoted context omitted.
Well performance aside there is also the benefit of not having to maintaining userland.
What are the overheads of maintaining userland? 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?
It also implies security due to reduced attack surface and non-standart interfaces.
Re: Atmanos: Build Go programs that run directly on the Xen hypervisor
#9I’d be interested to see performance comaprisons between this and Go on a Linux variant. Aside from performance, what are the alleged benefits of a unikernel? Security?
I agree. The performance difference is critical.
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?
Re: Atmanos: Build Go programs that run directly on the Xen hypervisor
#10I’d be interested to see performance comaprisons between this and Go on a Linux variant. Aside from performance, what are the alleged benefits of a unikernel? Security?
Much smaller attack surface.
Not really. Now instead of having to break the application, then break the kernel it's running under and then attack the VM host, you only have to attack the app and can then go directly at the VM host.
Unikernels just remove a whole security layer. May as well run the app as a user process on the host and forget the VM.