FreeBSD comes to Amazon's lightweight hypervisor
"Serverless" microVMs further blur the line between containers and virtual machines
The FreeBSD developer who brought FreeBSD to Amazon EC² has now got it working on the company's lightweight Firecracker hypervisor.
"AWS Community Hero" Colin Percival is the developer of the Tarsnap online backup service and the
portsnap tool for updating FreeBSD. It's thanks to his efforts that FreeBSD is supported on Amazon EC².
Now, he has announced that FreeBSD supports another new platform: Amazon's Firecracker hypervisor. The Reg covered Firecracker when it was announced, and when Amazon cut the price of the Fargate "serverless" platform that Firecracker supports. It's derived from the lightweight Rust-based crosvm which is part of Google ChromeOS.
This has meant making multiple adjustments to the FreeBSD kernel to allow for restricted set of services that Firecracker offers to its so-called "microVMs." For instance, Firecracker doesn't support ACPI and makes extensive use of Virtio. While FreeBSD already supported Virtio, it did so via ACPI calls, so that needed a rewrite.
Firecracker also informs the guest OS about the handful of devices in nonstandard ways: it was only really built to support Linux guests, although the OSv unikernel has also been ported to it.
The new FreeBSD support also meant changes to the hypervisor itself, such as incorporating existing patches to improve Firecracker's support of Xen-style PVH booting.
When we described Firecracker, we drew comparisons to other lightweight hypervisors such as Kata containers – which aren't really containers – and Google's gVisor, a kernel designed to run inside a container to make it more like a VM.
- NetBSD 9.3: A 2022 OS that can run on late-1980s hardware
- Disentangling the Debian derivatives: Which should you use?
- FreeBSD 13.1 is out for everything from PowerPC to x86-64
- The sad state of Linux desktop diversity: 21 environments, just 2 designs
Eleven years ago, when the Reg offered a brief history of virtualisation (and its second, third, fourth, and fifth installments), there was a clear distinction between hypervisors and the then-still-new-to-Linux tech of containers. A hypervisor emulates a whole computer, and runs an entire OS in each virtual machine, while containers all share the same kernel and run separate userlands on top.
Now, lightweight hypervisors and microVMs are blurring the lines between the two, as we described recently when talking about encrypting Kubernetes clusters. A microVM is an OS that knows it's running as a guest inside another OS, and which has been designed to talk to a hypervisor's services so that it doesn't need emulated hardware. The main ideas are that the guest can be much smaller, and can start much faster.
The flipside of this is "containervisors", notably Ubuntu's LXD. From comments in various forums, this seems to be one of Canonical's more popular and well-liked technologies. As opposed to Docker and its ilk, which focus on running a single app isolated in each container, LXD is explicitly designed to run an entire Linux OS (excluding the kernel) inside its containers, complete with its own init system. LXD even supports dedicating hardware to each container.
In other words, while containers are getting bigger and more complicated, VMs are shrinking down to rival the size and launch speed of containers. The more different OSes this supports, the better, we feel.