Comment 12 for bug 1660385

This is a pretty big issue for those of us not running inside any cloud environment, but still relying on non-intrusive ways to provision VMs.

I know that NoCloud is the expected datasource for that, but Ec2 was always a hassle-free option. It is trivial to spin up a Ec2-compatible metadata server, and then the only thing you need is to boot a vanilla ubuntu image with no strings attached, it will find ec2 metadata and will just work.

Compare this to NoCloud:

 - pass a kernel command line option, which requires to boot qemu with custom kernel outside of ubuntu guest image and is troublesome

or

- add config files into the guest's /var/lib/cloud/seed/nocloud, which requires mounting the image on the host and tinkering with it (and as soon as it's mounted, there's little reason to use cloud-init at all, TBH)

or

- add a virtual cd image with cloud metadata, which requires provisioning those images and some (at times) non-trivial bookkeeping, e.g. when you migrate a vm to a different host (two machines are still a NoCloud).

If you are going this route, I would highly suggest you to consider an option where NoCloud can be pointed at network server via, e.g. dmi strings, that are trivially configurable from qemu / libvirt.