[Boot]: Support for initrd_path

[andreeaflorescu]

With the initial API when specifying a kernel path, you could also specify the path of the initrd file.
For now this feature is not mandatory.
Acceptance Criteria: Decide if this feature is needed for other use cases.

[andreeaflorescu]

There is a topic in our FAQ related to this issue. Before closing it, please update the file.

[andreeaflorescu]

The support is added in PR #428

[rgooch]

I would like to see this feature added. It would allow replacing QEMU with Firecracker for a significant fraction of VMs.

[cpaelzer]

Yeah just like @rgooch I'd think for a more direct conversion of some qemu based workloads having initrd support would be great.

[tv42]

I feel like this is worth mentioning: people often want keep their initramfs separate from the kernel image to keep their lawyers happy.

This has the memory efficiency advantages of initramfs (no ramdisk block device) but the separate packaging of initrd (which is nice if you have non-GPL code you'd like to run from initramfs, without conflating it with the GPL licensed Linux kernel binary).

https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Then again, given that you'll likely need a special kernel build for these microVMs anyway (no SATA disk etc), I'm not sure one would have such a pressing need for an initramfs. They're usually used just to load the relevant kernel modules to be able to continue the boot, but in these use cases you should be able to build all that in.

I've ran plenty of VMs that only had an initramfs and no block storage at all, and in that scenario the license separation makes a lot of sense.

[tv42]

The FAQ has a typo: "You can track issue #228 for news on this topic." while the link leads to here, issue 208.

[luxas]

I think this would make a lot of sense, in order to be able to boot e.g. the stock Ubuntu/CentOS/Debian kernels, that all set CONFIG_VIRTIO_BLK=m and CONFIG_VIRTIO_NET=m. Hope to see this in the roadmap too #1104