Comment 2 for bug 1895976

I think the cloud-init logs won't help in this matter, as all they say is that 'the metadata could not be loaded, bad things to come'.

The problem is that Hyper-V exposes 'Virtual Machine' as product_name, thus this check fail: detect_openstack from https://github.com/canonical/cloud-init/commit/1efa8a0a030794cec68197100f31a856d0d264ab#diff-d0124efa9c349e076a076e7061eee70eR217.

I checked there seems Hyper-V does not have an API to set the product_name for a VM, but has an API to change the chassis tag to anything we would like. Even if that can be done, both nova and cloud-init have to be changed.

In case of cloud-init, another valid DMI chassis tag should be added here: https://github.com/canonical/cloud-init/commit/1efa8a0a030794cec68197100f31a856d0d264ab#diff-d0124efa9c349e076a076e7061eee70eR31

In case of nova, the valid tag should be set here: https://github.com/openstack/os-win/blob/master/os_win/utils/compute/vmutils.py#L369
vs_data.ChassisAssetTag= "OPENSTACK_ON_HYPERV"

See: https://docs.microsoft.com/en-us/windows/win32/hyperv_v2/msvm-virtualsystemsettingdata

But what I do not like is that everyone that wants to add in the future some other exotic or upcoming platform, it has to change code in both places. Also, these kind of changes are usually not deemed backwards compatible, so there is a valid point that the existent Ubuntu versions, for example, will never include that change.

That is why I suggest to create a new cloud-init per metadata config option (called like this: self.ds_cfg.get("perform_platform_check", True)), which when set to false, cloud-init shoud not perform platform checks.