OS-8711 - Support cloud-init NoCloud datasource for HVM guests

[travispaul]

Looking for feedback on the general approach being taken here to enable NoCloud Cloud-Init support. I anticipate further code changes and testing but I don't want to spend too much time if we'd like to approach this differently.

The original goal was to enable Talos support and in doing so I found the NoCloud approach to also simplify HVM image creation for other distributions as well.

With these changes, creating a new image is roughly following process:

1. Download a nocloud compatible image
2. dd it to a zvol
3. take a snapshot
4. Add a special tag on the image manifest so vmadm knows it supports nocloud

I have some examples here: https://github.com/travispaul/nocloud-images

Once you have a compatible image, the process at provisioning time is roughly:

1. Check for the special tag on the image being used
2. Create a 16MB disk with a FAT partition
3. Generate up to 4 specific YAML files with cloudinit data on the disk
4. When the OS boots, if it supports NoCloud, it will look for a filesystem with the CIDATA label and load the cloud init files.

To create the FAT filesystem lofiadm is being used, however I also experimented with a Claude generated FAT16 implementation that created the filesystem and wrote the files. The pure JS FAT module had less failure points and didn't exec anything but was a bit harder to review and was a little bit more code.

Portions generated by: Claude Opus 4.5 noreply@anthropic.com

[danmcd]

Nits for now. I have to page-in my old days of upstreaming a fix to cloud-init to make sure I'm not missing something.

[danmcd]

Typo 2026. AND missing license.

[danmcd]

MIssing license.

[danmcd]

Missing license.

[danmcd]

One more thing: Are there illumos distros (OmniOS or OI) that could benefit from this? If so, we should add one as the fifth example image.

[travispaul]

Thanks @danmcd ! I updated those files with the CDDL license header.

Regarding cloud-init behavior, I still have some testing to do there and some of the related code may change. I want to ensure we handle all the same keys that the mdata provider uses.

I'm curious if you have any reservations about the lofs approach to building the FAT image? Or any preference for a pure JS solution that avoids the shelling out to utilities?

I'm not sure what distros use this metadata-agent but there is a draft PR which adds nocloud support and appears to be looking for the same "CIDATA" labeled filesystem. I'll see if I can find an illumos image with existing support, that would be a great example to have.

[danmcd]

You're helping me remember things, thank yo.

Thanks @danmcd ! I updated those files with the CDDL license header.

Thank you for the update.

Regarding cloud-init behavior, I still have some testing to do there and some of the related code may change. I want to ensure we handle all the same keys that the mdata provider uses.

Yes yes yes... this was what I was trying to remember: canonical/cloud-init@55baf2d in particular.

I'm curious if you have any reservations about the lofs approach to building the FAT image? Or any preference for a pure JS solution that avoids the shelling out to utilities?

At creation time we have less worry about latency. Unless there are existing JS tools other parts of SmartOS/smartos-live are using, we can shell out. git grep may be your friend here.

Building the FAT image is exactly what lofs is for... we do this for our USB key construction. (And you may get angry with pcfs(4FS) flaws, but with a 16MB space, maybe not so much.)

I'm not sure what distros use this metadata-agent but there is a draft PR which adds nocloud support and appears to be looking for the same "CIDATA" labeled filesystem. I'll see if I can find an illumos image with existing support, that would be a great example to have.

From 2022, and it contains a conversation between OI's "Toasterson" and fellow illumos RTI advocate Josh Clulow. Toasterson isn't being rigorous in an illumos-gate way, it looks like, and nothing went anywhere after this.