“Firecracker is an open source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services that provide serverless operational models. Firecracker runs workloads in lightweight virtual machines, called microVMs, which combine the security and isolation properties provided by hardware virtualization technology with the speed and flexibility of containers.”
Happy to see the kernel init parameters fix land! For context, I used firecracker (very successfully) in a CTF, driven via a Discord bot.
One of the challenges I tried to build was one where a player would get access to the kernel commandline with the goal being that they should hack their way around the environment to get access to an encrypted disk. Unfortunately, that was when I get the now fixed bug[1].
The main feature Firecracker (and `crosvm`) is that they offer very trimmed-down VM's: you get disk, network, and serial (and KVM of course); that's it.
Thus if you don't need the emulation (and other extra features) from QEMU, it can be simpler to configure and certainly more secure to run.
For example I intend to run development VM's on Firecracker instead of QEMU.
Unless your homelab and/or business is about providing (not consuming) serverless infrastructure efficiently at scale then firecracker isn't really worth considering IMO. That doesn't mean you can't use it in other use cases if you really want but that's what it was designed for/to do well with.
Firecracker uses KVM, but KVM is only part of the equation. KVM exposes some very basis functionality (vcpus, memory) that an application like Firecracker or rust-vmm (or more commonly QEMU) use to create a Virtual Machine. The Virtual Machine usually needs additional components that are outside of the scope of KVM, such as serial ports, disks, network interfaces, BIOS which the VMM emulates. In the case of Firecracker, the emulation layer is much simplified and doesn't necessarily aim to replicate a real machine (QEMU sort of does), but one that has the bare minimum to function. This is done so that it's faster to boot and uses less resources overall.
I'm not sure this answers your questions exactly, there are good reasons to sometimes use a more faithful emulation of a real machine, but it's also sort of legacy for many of the cloud use cases like multi-tenant architectures, where VMs are mainly used to keep hard boundaries between customers.
Sorry for a meta question but is the "Show HN" tag correctly applied? I tried to check if the poster is a developer of Firecracker, but unless that their contributions were pre-GitHub, I don't think that the tag qualifies.
P.S.: I'm not the author, nor am I involved with Firecracker; however given they've just released v1.0.0, and no-one shared it, I thought it would be worth pointing at it.
> Any thoughts? How should I tag such links in the future?
One does not necessarily tag such submissions. A link to the page with the title unedited (edited iff the title is inadequate or is a clickbiat), is more than enough.
If you must tag such submissions, Tell HN seems the best suited.
Tell HN is not a good tag for such submissions, the right thing is just not trying to gussy up your submissions - a cornerstone principle of HN. Everything posted to HN is someone telling or showing something, the tags are highly specialized. If unsure, just don't use the tags.
