On Fri, Mar 06, 2020 at 09:44:26AM +0100, João Mikos wrote: > Reflecting about what you said the default kernel might indeed not be > the best place to enable this, but maybe the cloud kernel could be a > good candidate instead. Official support for Firecracker might be a > stretch, especially due to the goals you've mentioned, but I am seeing > projects (e.g. Ignite) using Firecracker as a basis. Any such derived > project would be benefited by this change. But indeed, the kernel team > has the best view on whether they want to support (with all that > entails) any new flag or feature.
On the contrary, tools that integrate Firecracker directly, like Ignite, Kata Containers, and firecracker-containerd, are the ones that will benefit the most from using a custom kernel. Indeed, all of those projects provide their own kernel images for use with Firecracker. These kernel images are configured to omit drivers for devices that are not present in Firecracker's device model, some of of which lead to long delays in the boot process while they probe for nonexistent devices. Support for Firecracker in the default Debian kernel could be interesting for experimentation, but I think you'd want to switch to a customized kernel as soon as possible before running in production. Given that the kernel in a Firecracker MicroVM is loaded by the host, rather than being embedded in the guest VM image, I think a kernel supporting Firecracker might be better handled in a manner similar to the user-mode-linux kernel package. https://packages.debian.org/buster/user-mode-linux That would be a package that'd be installed on the system hosting MicroVMs, where it could provide an uncompressed kernel image for use by Firecracker. noah
