Comment 2 for bug 1669875

I ran into this recently and had a quick sniff around for a solution. I noticed that in https://bugs.launchpad.net/cloud-init/+bug/1756471 the Open Telekom Cloud folks made use of the chassis asset tag field to ensure proper detection. Scott, is there any reason we couldn't use the same approach for VMware as well (and potentially others who have DMI/SMBios support)? As it happens, asset tag is a field we can set. E.g. you can create a flavor with a property like this:

openstack flavor create --ram 2048 --disk=20 --vcpus=2 --public --property vmware:extra_config='{"smbios.assetTag":"OpenStack Nova"}' m1.small.test_assetTag

When an instance is booted, this in turn will get passed into the VM's VMX file and then show up in dmidecode output on the guest:

<snip>
Chassis Information
        Manufacturer: No Enclosure
        Type: Other
        Lock: Not Present
        Version: N/A
        Serial Number: None
        Asset Tag: OpenStack Nova
</snip>

By way of a quick test, I used a Bionic cloud image (with cloud-init 18.5-21-g8ee294d500ubuntu1~18.04.1) with a flavor set up like so to take advantage of the existing fix for Open Telekom Cloud:

openstack flavor create --ram 2048 --disk=20 --vcpus=2 --public --property vmware:extra_config='{"smbios.assetTag":"OpenTelekomCloud"}' m1.small.test_assetTag

After booting an instance with this flavor on a VMware-backed deployment, I see that cloud-init did fetch metadata properly.

If this seems ok, I'd be happy to look into a patch that allows cloud-init to recognize "OpenStack Nova" (or perhaps "OpenStack Compute"?) in the asset tag field, which seems generic enough that others could use it too if need be. We could also look into a Nova driver patch to ensure the assetTag gets set by default rather than making everyone manually set flavor properties.