>> Notably, none of these services are "unikernel-friendly" in that they don't >> provide any mechanism to pass arguments to the kernel, other than embedding >> them into the bootloader in the machine image.
Correct, grub launches the kernel and passes arguments to the kernel in all scenarios I’ve seen on the cloud instances. This is the way rump (and MirageOS/Ling/HalVM) kernels are launched on EC2 - embedding them into the bootloader in the machine image via grub. Systems that provide a direct kernel boot mechanism (like KVM or for example https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sub-sect-op-sys-dir-kern-boot.html) always need to provide a mechanism for passing kernel arguments. >> Additionally, we could download the instance-specific metadata blob during >> boot and merge(?) any configuration found there with what has already been >> packaged in the machine image. Thoughts? Arguments to the kernel would work in any context at all that a kernel could be launched (same approach for Xen/PV/HVM, KVM, EC2/PV/HVM, GCE, Azure local or cloud etc) whereas cloud userdata blobs is platform specific - FWIW I’d err towards the standard mechanism for kernel config via arguments. Apart from the above points, everything you say sounds right to me. Diskless by default, auto DHCP and auto mounted block devices would be make things “just work” and remove the need for any configuration in some cases. +1 as
