This project mentions it’s based on the Xen hypervisor and uses EC2 as an example for running it, but haven’t AWS now moved to their own KVM based hypervisor? Would this still work?
You can still choose Xen-based instances in EC2.
MirageOS 4.0 – Self-managed internet infrastructure with unikernels
31–38 of 38 posts
Re: MirageOS 4.0 – Self-managed internet infrastructure with unikernels
#32Earlier quoted context omitted.
In ancient times, only Xen was supported. Nowadays, the support moved to: - Xen (PVH) - Linux KVM, FreeBSD BHyve, OpenBSD VMM - SPT (seccomp, no hardware virtualization) - virtio (GCE, ..) - muen (muen.sk) Take a look at https://github.com/solo5/solo5 which is used as the low level bits to run OCaml.
> - SPT (seccomp, no hardware virtualization) To be clear, this means running an ordinary Linux binary, right? I'm curious about the remaining advantages in practice of running multiple processes on a shared kernel rather than using hardware virtualization. I guess the main one is more efficient resource pooling, particularly memory and the page cache. I understand the primary advantage of virtualization is a smaller…
Re: MirageOS 4.0 – Self-managed internet infrastructure with unikernels
#33Re: MirageOS 4.0 – Self-managed internet infrastructure with unikernels
#34Re: MirageOS 4.0 – Self-managed internet infrastructure with unikernels
#35Earlier quoted context omitted.
Ahh ok. I imagine you would lose all the nice Nitro stuff though like enhanced networking etc which is a bummer.
There is Xen-on-Nitro, which AWS developed to continue to support customers using Xen to run on EC2 instances featuring Nitro: https://perspectives.mvdirona.com/2021/11/xen-on-nitro-aws-n...
Re: MirageOS 4.0 – Self-managed internet infrastructure with unikernels
#36Earlier quoted context omitted.
What about multiprocessing? I assume that MirageOS can take advantage of multiple cores (or do you need separate instances per core?). In this case is the system still shared memory? Also I would say there are reasons for isolation beyond memory safety.
MirageOS is - similar to the latest OCaml release - only using a single CPU core. You can run multiple unikernels, one on each core. If doing that, you can use Xen vchan (shared memory), or TCP for marshalling. > Also I would say there are reasons for isolation beyond memory safety. Would you mind to elaborate which reasons you are thinking of?
How does it go when you deploy a unikernel on EC2 (or on any IaaS where the hypervisor is managed unlike bare-metal) with multiple cores? Is there a way to start a unikernel per core on a single instance, or are you bound to use single core instance types only?
Re: MirageOS 4.0 – Self-managed internet infrastructure with unikernels
#37Does MirageOS exclusively support native Ocaml applications? Or does it appear to applications like a standard OS, so you can develop with anything? For example, they show how you can host a static site. Great, but can I run my Flask API?
If you want a POSIX unikernel have a look at Unikraft.
Re: MirageOS 4.0 – Self-managed internet infrastructure with unikernels
#38Earlier quoted context omitted.
What about multiprocessing? I assume that MirageOS can take advantage of multiple cores (or do you need separate instances per core?). In this case is the system still shared memory? Also I would say there are reasons for isolation beyond memory safety.
MirageOS is - similar to the latest OCaml release - only using a single CPU core. You can run multiple unikernels, one on each core. If doing that, you can use Xen vchan (shared memory), or TCP for marshalling. > Also I would say there are reasons for isolation beyond memory safety. Would you mind to elaborate which reasons you are thinking of?
Thanks. Is that going to change now that OCaml is finally getting proper multicore support?
>> Also I would say there are reasons for isolation beyond memory safety. >Would you mind to elaborate which reasons you are thinking of?
Memory safety in a sense protects the integrity of the 'runtime', but only partially help to protect business level integrity. A task might still tricked (by mistake or malice) to access objects it is not supposed to. I'm sure that OCaml has enough abstractions to help prevent that, but full isolation of tasks is a blunt and effective tool.