The open-source MirageOS unikernel project reached a major milestone on Feb. 23, with the launch of MirageOS 3.0. The basic idea behind a unikernel is that it is a highly-optimized and purpose-built, operating system that can help to enable efficient operation and delivery of applications.
The MirageOS 1.0 release debuted back in December 2013 as an effort led by the Linux Foundation’s Xen hypervisor virtualization project. With the new MirageOS 3.0 release, the unikernel is now expanding beyond the confines of the Xen hypervisor and now also supports the KVM and Bhyve hypervisors as well.
What has also changed since the MirageOS 1.0 release is the ownership of Unikernel Systems, which is one of the lead developers behind MirageOS. Docker Inc. acquired Unikernel Systems in January 2016.
“MirageOS has continued to be an open-source unikernel project that is an incubation project of the Xen Project,” Anil Madhavapeddy, MirageOS project lead, told eWEEK. “The project hasn’t changed since the acquisition of Unikernel Systems; however the library ecosystem has grown a lot: we now have more than 350 contributors across hundreds of repositories.”
MirageOS defines itself as a ‘library operating system’, meaning it can be deployed to run on any target system where the necessary drivers and bootloader are present. Madhavapeddy explained that with the MirageOS 3.0 release there are major improvements to developer experience as well as a core library API refactoring for improved portability and performance. The addition of the new hypervisor targets, with KVM and Bhyve, is also a big deal since prior releases of MirageOS only supported the Xen hypervisor running on Linux, BSD and macOS.
“MirageOS 3.0 adds the second hypervisor target in the form of KVM, via the Solo5 project contributed by IBM,” Madhavapeddy said.
He added that Solo5 adds the ‘virtio’ and ‘ukvm’ targets, which are now fully integrated with the Mirage frontend tool. The two targets serve different use-cases with virtio for running on public clouds, such as Google Compute Engine, that emulates conventional virtual networking. Madhavapeddy explained that the ukvm target is a far simpler device mode that is specialized for unikernel use only, and only requires KVM kernel support instead of any userspace device emulation.
“It was quite a bit of work to generalize MirageOS 3 for all these architectures, but there is a new configuration language that makes it all very manageable,” Madhavapeddy said. “We now have early users of MirageOS 3 happily deploying their websites on FreeBSD Bhyve, Xen, KVM on Debian, and even experimentally directly on macOS via the Hypervisor framework.”
The fact that MirageOS can now run on hypervisors other than Xen, isn’t a problem for the Xen Project. Lars Kurth, Chairperson of the Xen Project Advisory Board, commented that the Xen Project has been a big proponent and supporter of unikernels early on.
“Being an incubation project of the Xen Project has provided MirageOS with the infrastructure support that they needed to kick this initiative off the ground,” Kurth told eWEEK.
Kurth added that there was always the potential to have MirageOS work with other hypervisors to bring the capabilities of unikernels to other environments. He noted that the Xen Project sees this as the next phase of growth for unikernels and is very excited to continue to support MirageOS to bring this key technology to the entire systems maker community.
MirageOS is already being used to by Docker Inc. to enable its Docker for Mac and Windows applications. Madhavapeddy explained that the Docker engine is running in an Alpine Linux distribution on top of a custom library hypervisor on macOS or on a Hyper-V virtual machine (VM) on Windows, and that VM is managed by the Docker application.
“Every single network packet from a container running on the Mac application is reconstructed via the MirageOS TCP/IP stack, which is a solid vote of confidence in the overall stability of Mirage 3,” Madhavapeddy said.
While Docker is making use of MirageOS components, containers and unikernels are two different ways of delivering applications. A unikernel provides operating system level components, while a container relies on the host operating system.
“Regarding the intersection between Docker and unikernels, we believe that unikernels and containers sit on a continuum,” Madhavapeddy said. “Ultimately, we want to make it easy for developers to be able to build, ship, and run their code using a familiar and coherent tool chain — regardless of whether the application is in a container, or built as a unikernel, or whatever comes next.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.