On Friday, 25.09.2015 at 20:14, Andrew Stuart wrote: > 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.
That's fine, systems with direct kernel boot fall under the scope of either the "rumplaunch" tool, or "do it yourself manually". > >> 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. Yes, arguments to the kernel will "work" in the sense that there is always a way you can embed these arguments into the image. However, my point is that with cloud hypervisors it is not *practical* to build (and import, and register, and whatnot) a new machine image just for the sake of specifying different arguments to the unikernel.
