[HN Gopher] Firecracker: Lightweight Virtualization for Serverle...
___________________________________________________________________
Firecracker: Lightweight Virtualization for Serverless Applications
Author : andrioni
Score : 62 points
Date : 2020-02-18 17:55 UTC (5 hours ago)
(HTM) web link (www.amazon.science)
(TXT) w3m dump (www.amazon.science)
| srmatto wrote:
| I'm really excited to see where this goes in the community. There
| are some interesting projects using Firecracker such as Weave
| Ignite and firekube that I think could improve the security of
| Kubernetes. Also lightweight VMs are exciting in their own right.
|
| https://github.com/weaveworks/ignite
|
| https://github.com/weaveworks/wks-quickstart-firekube
| bonzini wrote:
| How does firekube compare to Kata Containers?
| nezirus wrote:
| I've also had great fun with Firecracker and virt-builder
| (http://libguestfs.org/virt-builder.1.html) as a way to prepare
| and use generic distros on Firecracker.
|
| (The only additional step is to use guestfish to "download" root
| partition from disk image created with virt-format and virt-
| builder)
| steveklabnik wrote:
| Firecracker is a very interesting project.
|
| It's covered in the paper, but the origins are the "crosvm"
| project at Google, which is used in ChromeOS. Firecracker started
| as a fork of crosvm, removed a bunch of code they didn't need,
| and of course adding their own.
|
| But rather than just fork, they've consolidated the shared parts
| into the "rust-vmm" project: https://github.com/rust-
| vmm/community
|
| > The rust-vmm project is organized as a shared effort, shared
| ownership open-source project that includes (so far) contributors
| from Alibaba, AWS, Cloud Base, Crowdstrike, Intel, Google, Red
| Hat as well as individual contributors.
|
| This has allowed other similar tech to grow, like
| https://github.com/cloud-hypervisor/cloud-hypervisor, which seems
| to be the Intel project mentioned in the above sentence.
| bonzini wrote:
| The comparison with QEMU is a bit disingenuous. The number of
| lines of code in a given binary is much less than 1.4 million,
| which is the total for all the architectures that QEMU supports
| (actually it's closer to 2 million). It is also possible to
| configure out a lot of the code and libraries. A default build is
| around 6-700.000 lines of code, and it is possible to build
| reduced versions that tally less than 300.000 lines just by
| tweaking a configuration file with the list of included devices
| (which was done for the experiments in the paper). The NEMU
| project mentioned in the paper is inactive exactly because it was
| a dead end: it was possible to achieve all their goals directly
| in QEMU without the need for a fork.
|
| Likewise, the number of syscalls in QEMU (270) is quoted from
| another paper but likely refers not to QEMU used as a VMM, but
| rather to the so called "user-mode emulation" that runs foreign
| Linux binaries (and which, by its very nature, invokes pretty
| much all Linux syscalls including quite a few obsolete ones).
|
| It would be interesting to have more information on the
| configuration they use for QEMU, especially whether they are
| enabling PCI and ACPI. Version 4.2 of QEMU (the version they
| used) has a trimmed virtual machine type that was admittedly
| inspired by Firecracker and actually boots even faster than
| Firecracker, or at least in the noise. [1] The code specific to
| this machine type is only 500 lines. Also since that release QEMU
| and qboot _are_ actually able to boot uncompressed kernels using
| the PVH entry point, contrarily to what the paper states. This
| could explain the difference in boot time performance.
|
| Memory consumption is tricky, QEMU uses green threads and has to
| allocate stacks for them. This can show up as large mmaps but
| they do not correspond to actual memory usage. But again without
| redoing the experiments it's hard to say if that is the cause. I
| have no doubt Firecracker is leaner in this respect, anyway, and
| it's an important metric for Amazon.
|
| That said, I am all for competition, and some of the measurements
| in the paper are certainly worth a look to see if there is more
| low hanging fruit to pick, especially with respect to memory
| consumption. QEMU is a complex program, as demonstrated by the
| complexity of measuring it accurately, and Firecracker is a very
| interesting project. I am very happy to collaborate with the
| authors of the paper on rust-vmm.
|
| [1] http://people.redhat.com/pbonzini/microvm/
| deforciant wrote:
| We have been using it to run e2e tests by creating multiple VMs
| that need to talk to each other and load some kernel modules. It
| works so much faster than relying on cloud providers or
| alternatives like Docker in Docker. Very good impressions so far
| :)
| eatonphil wrote:
| What Firecracker frontend are you using? Or are you programming
| directly against the builtin VMM API?
___________________________________________________________________
(page generated 2020-02-18 23:00 UTC)