Re: virtio_mmio.device parameter unknown as kernel config option is disabled
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
Reply to: