All, I'm finding myself needing to pass in some information to cloud-init in some VM's in a non-cloud environment.
cloud-init is a (very) widely used tool for applying some initial configuration to VM's. It originally exclusively used AWS's EC2's metadata and userdata service, but has since been extended to use many other configuration sources. The volume of the configuration varies a lot. For my use, they will be several kB (passing in various certificates, etc.). For non-cloud environments, the traditional source for user-data configuration has been an ISO with the relevant configuration files. This feels anachronistic to me. I raised a feature request with cloud-init to have it support fw_cfg as a configuration source: https://bugs.launchpad.net/cloud-init/+bug/1879294 I was told that there was already a feature request to use SMBIOS fields to do the same: https://bugs.launchpad.net/cloud-init/+bug/1753558 Dan Berrangé (of libvirt fame) pointed out (in that latter bug report) that the qemu developers advised against using fw_cfg for this sort of thing. I have no particular reason to doubt him, but I'd still like to hear from the horse's own mouth and try to understand why. While I can certainly find a way to serialize my config blob into a single string with no NULLs (per SMBIOS spec) and pass it in through the SMBIOS interface, the fw_cfg approach seems a whole lot simpler for both the user and for cloud-init. Also, having gotten so used to cloud-init just being there, personally it doesn't feel like much of a stretch to think of it as a sort of firmware. Can someone enlighten me on why using fw_cfg is the wrong way to go? Best regards, Soren L. Hansen
