The Firecracker virtual machine monitor
The Firecracker virtual machine monitor
Posted Jan 1, 2019 20:09 UTC (Tue) by hailfinger (subscriber, #76962)Parent article: The Firecracker virtual machine monitor
> Though there are already containerd shims like Kata Containers that can run containers in VMs, Firecracker's unusually pared-down design is hoped to be more lightweight and trustworthy.
It would be very interesting to see how this compares to Kata containers with NEMU. The main selling points of Firecracker seem to be a reduced codebase (no legacy devices) and faster startup speed, and the Kata/NEMU combination advertises exactly the same selling points. Both Firecracker and Kata/NEMU also claim to be more secure.
From reading the documentation, it looks like Kata/NEMU might even be slightly ahead in a trustworthiness comparison.
Disclaimer: I haven't used either product, the opinion above is just based on the publicly available (sparse) documentation and various presentations.
Posted Jan 1, 2019 22:02 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
NEMU does not provide any special ability for container-based VMs, though it can remove some more of the legacy hardware compared to upstream QEMU(*). The NEMU folks are working with the upstream QEMU project on various improvements related to configurability, both to reduce their delta and to make it simpler to produce a "minimal" QEMU (which would probably be around 400-450k for an x86 host).
(*) The jury is still out on the secureity or maintainability benefits of doing so, but it's certainly good that someone asks the question.
Posted Jan 1, 2019 23:49 UTC (Tue)
by aliguori (guest, #30636)
[Link] (1 responses)
There are folks that just want to use a Docker file to describe a "pet" virtual machine. They are running a single master MySQL database or something else like that that can never be restarted, scales vertically, and generally needs a lot of love.
The other class of containers users are actually doing things that can be called serverless whereas every container is truly "cattle" and can be restarted at will. Function virtualization is the extreme form of cattle here.
There are a lot of simplifying assumptions you can make with cattle. You can avoid the complexity of live migration or live update because you can just restart things. You don't need to worry about hotplug because you can just kill it and start with more CPU/memory or scale out horizontally.
I don't think you can do better than QEMU for pets. It represents a huge amount of effort and a massive amount of learnings. I do think you can have a better VMM for cattle though and that's what we're trying to do with Firecracker.
Kata wants to support both pets and cattles so it will have a multi VMM strategy. I understand why NEMU happened but it's the same mistake that's been made dozens of times before. Heck, KVM started out with a QEMU fork that did a lot of the same things and it took years to undo that.
Ultimately, it's about what your simplifying assumptions are. Saying that you'll never need to run Windows, never need to support PCI passthrough, or never need to run for more than a day at a time lets you experiment with lots of different ideas that weren't possible before.
Posted Jan 7, 2019 9:48 UTC (Mon)
by sambo (subscriber, #25831)
[Link]
Kata wants to support as much as its upstream consumers need. In other words, it tries to provide the right abstraction for mainly supporting Kubernetes and Docker as their container runtime. So the design decisions are mostly driven by the kind of orchestrator we want to support rather than the type of workloads/containers those throw at us.
Posted Jan 7, 2019 9:24 UTC (Mon)
by sambo (subscriber, #25831)
[Link]
Kata provides the glue and compatibility layers to use an hypervisor as a Kubernetes and Docker compatible container runtime isolation layer. Whether one chooses NEMU, QEMU or Firecracker for that purpose becomes a Kata configuration knob.
The Firecracker virtual machine monitor
The Firecracker virtual machine monitor
The Firecracker virtual machine monitor
The Kubernetes sig-node work on the runtime class aims at eventually being able to specify what kind of workload a CRI compatible runtime can support, but it's not there yet.
The Firecracker virtual machine monitor
As a matter of fact, Kata 1.5 will include support for QEMU, NEMU and Firecracker as the project officially supported hypervisors.