identify openstack vmware platform

[Scott Moser]

We need a way to identify locally that we are running on openstack when inside a guest of VmWare.

Related bugs:
  https://bugs.launchpad.net/cloud-init/+bugs?field.tag=dsid-nova

[Scott Moser (smoser)]

Some info:
$ ( cd /sys/class/dmi/id && sudo grep -r . * )
bios_date:09/21/2015
bios_vendor:Phoenix Technologies LTD
bios_version:6.00
board_name:440BX Desktop Reference Platform
board_serial:None
board_vendor:Intel Corporation
board_version:None
chassis_asset_tag:No Asset Tag
chassis_serial:None
chassis_type:1
chassis_vendor:No Enclosure
chassis_version:N/A
modalias:dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd09/21/2015:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
power/control:auto
power/async:disabled
power/runtime_enabled:disabled
power/runtime_active_kids:0
power/runtime_active_time:0
grep: power/autosuspend_delay_ms: Input/output error
power/runtime_status:unsupported
power/runtime_usage:0
power/runtime_suspended_time:0
product_name:VMware Virtual Platform
product_serial:VMware-42 06 94 a2 6c e8 2b 6e-f0 c7 e7 5c cb c5 36 c9
product_uuid:420694A2-6CE8-2B6E-F0C7-E75CCBC536C9
product_version:None
sys_vendor:VMware, Inc.
uevent:MODALIAS=dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd09/21/2015:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:

$ dmidecode
http://paste.ubuntu.com/24103596/

[Mark T. Voelker (mvoelker)]

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.

[Scott Moser (smoser)]

Mark,

That sounds like a good solution.
I think that 'OpenStack Nova' is the "right" value (per upstream source), but as found in bug 1675349 'OpenStack Compute' needs to also be accepted.

Thanks for the digging, and that 'openstack flavor create' option is *really* helpful. Thanks.

[Mark T. Voelker (mvoelker)]

Sure thing. I'll have a look at a patch that includes both values soon; it looks pretty straightforward. We're also prototyping a driver patch that would introduce a new strOpt config option for Nova that would allow admins specify a string which would be set as the assetTag on all new instances (unless overridden by an extra spec).

By the way, for anyone else who stumbles upon this via search engines, there are two ways to mitigate this today on existing versions of cloud-init.

1.) The flavor extra spec method mentioned above.

2.) By setting a property on the image. This allows you to set the assetTag just on particular images which are known to carry an affected version of cloud-init (e.g. you can set the assetTag on your Bionic images but not your Xenial images, for example).

If you have instances using a version of cloud-init that predates the forthcoming patches I mention above, a workaround is to use either of these two methods to set "smbios.assetTag" to "OpenTelekomCloud".

[Server Team CI bot (server-team-bot)]

This bug is fixed with commit deaeb714 to cloud-init on branch master.
To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=deaeb714

[Ryan Harper (raharper)]

This bug is believed to be fixed in cloud-init in version 19.2. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

[Mark T. Voelker (mvoelker)]

Because we've had a some folks stumble across this bug and ask about it recently I thought I'd document this here for posterity:

For those using the VMware Integrated OpenStack distribution, we've added a minor tweak to the Nova driver to set the asset tag by default to a value specified in nova.conf. This means that users won't have to set the asset tag using extra specs/image attributes (though if they wish to do so, using vmware:extra_config='{"smbios.assetTag":"OpenStack Compute"}' will override the value set by default in the driver).

If you're using any of the following versions of VMware Integrated OpenStack you should have the patch:

* 4.1.2.2 or newer
* 5.1.0.2 or newer
* 6.0 or newer

If you'd like to modify the value set by the driver, look for "nova_set_asset_tag" in your custom.yml file, set the value you want, and run "viocli deployment update" to apply.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2819