Fix inventory plugin broken with AzureStackHCI vms and also fix ScaleSets network interfaces

[TiTi]

SUMMARY

Fix of #2074

• Prevents failure if inventory also contains AzureStackHCI vms (or just arc vms)
• Remove duplicate calls to instance view REST endpoints
• Fix original problem when retreiving scale sets vms network interface properties
  => will provide scale set private ip under private_ipv4_addresses host var
• Simplify logic

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

inventory plugin

ADDITIONAL INFORMATION

The original issue was : _on_nic_response was never called for scale sets nics, despite call to inventory_client._enqueue_get(url=nic['id'], being made

To reproduce issue:
az rest --url "/subscriptions/<subscription_id>/resourceGroups/<rgName>/providers/Microsoft.Compute/virtualMachineScaleSets/<scaleSetName>/virtualMachines/<vmId>/networkInterfaces/<NicName>?api-version=2024-05-01"

Which returns:
Bad Request({"error":{"code":"NoRegisteredProviderFound","message":"No registered resource provider found for location 'westeurope' and API version '2024-05-01' for type 'virtualMachineScaleSets/virtualMachines/networkInterfaces'. The supported api-versions are '2015-05-01-preview, 2015-06-15, 2016-03-30, 2016-04-30-preview, 2016-06-01, 2016-07-01, 2016-08-01, 2016-09-01, 2017-03-30, 2017-12-01, 2018-04-01, 2018-06-01, 2018-10-01, 2019-03-01, 2019-07-01, 2019-12-01, 2020-06-01, 2020-12-01, 2021-03-01, 2021-04-01, 2021-07-01, 2021-11-01, 2022-03-01, 2022-08-01, 2022-11-01, 2023-03-01, 2023-07-01, 2023-09-01, 2024-03-01, 2024-07-01, 2024-11-01, 2025-04-01'. The supported locations are 'eastus, eastus2, westus, centralus, northcentralus, southcentralus, northeurope, westeurope, eastasia, southeastasia, japaneast, japanwest, australiaeast, australiasoutheast, australiacentral, brazilsouth, southindia, centralindia, westindia, canadacentral, canadaeast, westus2, westcentralus, uksouth, ukwest, koreacentral, koreasouth, francecentral, southafricanorth, uaenorth, switzerlandnorth, germanywestcentral, norwayeast, jioindiawest, westus3, swedencentral, qatarcentral, polandcentral, italynorth, israelcentral, spaincentral, mexicocentral, malaysiawest, newzealandnorth, indonesiacentral, austriaeast, chilecentral'."}})

[Fred-sun]

line too long (178 > 160 characters)

[TiTi]

fixed :)

plus i've added some logging :) :) :) check out with -vvvv or debug=true in your ansible.cfg

[TiTi]

i have another small patch ready to fix another 'bug' in azure stack hci inventory, but it's unrelated so i'll wait for this to be merged as some lines are common and would it would create a conflict

[TiTi]

any update @Fred-sun ?

[Fred-sun]

@TiTi Thank you very much for your update. Could you resolve the conflict first? Am I giving it a try? Thank you!

[Fred-sun]

The normal VM and Uniform VMSS instance vm work fine. I will create a Azure Stack HCI VM for test! Thank you very much!

[Fred-sun]

expected 2 blank lines, found 1

[TiTi]

it's fixed

[TiTi]

any progress?

[TiTi]

Hello, is there a reason my PR is not approved?

[zunyangc]

Hi @TiTi, sorry for the slow progress on this PR. As I currently still do not have access to a pre-deployed Azure Stack HCI VM that is registered via Azure Arc, I couldn't validate this PR, hope for your understanding.

If you are able, please provide HCI validation results or any sample inventory output from an HCI environment. This would help confirm the changes and ensure the fix works as intended.

Let me discuss with the team and see how we can proceed further. Thanks!

[TiTi]

Hi @TiTi, sorry for the slow progress on this PR. As I currently still do not have access to a pre-deployed Azure Stack HCI VM that is registered via Azure Arc, I couldn't validate this PR, hope for your understanding.

If you are able, please provide HCI validation results or any sample inventory output from an HCI environment. This would help confirm the changes and ensure the fix works as intended.

Let me discuss with the team and see how we can proceed further. Thanks!

Ok i understand. Indeed having an HCI is a complex requirement.
I have access to a lot of HCI clusters, that's why I made this PR and how I tested it :-)

[Klaas-]

This also fixes #2125

but it does condense os_computer_name and computer_name into one thing. Not sure if that is wanted behavior. From my understanding:
computer_name is currently this: https://learn.microsoft.com/en-us/rest/api/compute/virtual-machines/get?view=rest-compute-2025-04-01&tabs=HTTP#osprofile
os_computer_name is https://learn.microsoft.com/en-us/rest/api/compute/virtual-machines/instance-view?view=rest-compute-2024-11-04&tabs=HTTP&tryIt=true&source=docs#virtualmachineinstanceview

so the first one is the "creation" input, the 2nd one is the actual runtime hostname as reported by walinuxagent

[Klaas-]

If you are able, please provide HCI validation results or any sample inventory output from an HCI environment. This would help confirm the changes and ensure the fix works as intended.

I can confirm it works for arc machines :)

[TiTi]

This also fixes #2125

but it does condense os_computer_name and computer_name into one thing. Not sure if that is wanted behavior. From my understanding: computer_name is currently this: https://learn.microsoft.com/en-us/rest/api/compute/virtual-machines/get?view=rest-compute-2025-04-01&tabs=HTTP#osprofile os_computer_name is https://learn.microsoft.com/en-us/rest/api/compute/virtual-machines/instance-view?view=rest-compute-2024-11-04&tabs=HTTP&tryIt=true&source=docs#virtualmachineinstanceview

so the first one is the "creation" input, the 2nd one is the actual runtime hostname as reported by walinuxagent

Hello and thank you. Indeed i didn't say it but it also solves the perf. issue, because removing (potentially lots of) uneeded requests.

Regarding os_compute_name (not os_computer_name), your right. However this was added in the 3.9.0 version with the PR i'm fixing: https://github.com/ansible-collections/azure/pull/2055/files
I find this property unhelpful and the naming confusing. People could also pick the "wrong" one initially (computer_name) and if the os name is changed, it's not reflected in the ansible inventory....
(we also have inventory hostname and name property)
Possible to add it though, what do you guys prefer?

[TiTi]

This is getting more and more challenging to handle conflicts as other PR are merged (and as i have other changes planned), but i managed.

Note: for hci this PR is unsufficient and a micro pr is needed to avoid errors in output if you fetch both HCI vms and others arc objects (code is ready on my machine). Error would typically be confusing:
[ERROR]: {'error': {'code': 'NoRegisteredProviderFound', 'message': "No registered resource provider found for location 'brazilsouth' and API version '2024-01-01' for type 'virtualMachineInstances'. The supported api-versions are '2023-07-01-preview, 2023-09-01-preview, 2024-01-01, 2024-02-01-preview, 2024-05-01-preview, 2024-08-01-preview, 2024-10-01-preview, 2025-02-01-preview, 2025-04-01-preview, 2025-06-01-preview, 2025-09-01-preview'. The supported locations are 'eastus, westeurope, southeastasia, australiaeast, canadacentral, southcentralus, japaneast, centralindia, uksouth'."}}

However i prefer to keep this PR as simple as possible for readability as we have already multiple changes:

• mostly a rollback of Support gather virtual machine instance view info #2055
• proper fix with usage of self._type
• debugging display and levels

---

@Klaas- you're right after review i'm changing behavior of computer_name compared before 3.9.0
but i believe it's better: to reflect the real computer name... looking forward you're pov

[TiTi]

Fix i'm talking about is mostly replacing this:

for arcvm in response['value']:
            url = '{0}/providers/Microsoft.AzureStackHCI/virtualMachineInstances'.format(arcvm['id'])

by this

for arcvm in response['value']:
            if archcivm.get('kind') == 'HCI':
                url = '{0}/providers/Microsoft.AzureStackHCI/virtualMachineInstances'.format(arcvm['id'])

but i also want to rename 'arcvm' objects and properties to 'archcivm' because it's more explicit and differs from real ArcHost(arcvm, ...) which is non-hci
and this creates lots of replacements => i prefer another PR

[Klaas-]

so general answer, os_computer_name / computer_name I personally don't care too much about them because I am not using them from inventory :D from a compatibility perspective I would say don't break existing behavior unless the MSFT people here are up for a major version increase.

Now if you ask me what should happen with the inventory generally speaking, I think what we do here should not be done here :) We should not be making up our own names for variables and completely rely on the azure python sdk, I've opened a "big issue" for that #2130 . Having said all that, this is not going to be short term solution because I guess I have to first convince msft of actually documenting the batch endpoint, then getting it into the sdk, then we can start using it :)

For shortterm changes, the smaller you can make your PRs the easier it is to merge them for the MSFT people, stuff like HCI and/or ARC is a problem because they don't have this in their test environment apparently...

[TiTi]

Simple example:

plugin: azure.azcollection.azure_rm
auth_source: auto
include_vm_resource_groups:
 - rg-ind4-prd-eu-riihimaki
include_hcivm_resource_groups:
  - rg-ind4-prd-eu-riihimaki

---

More complex example with multiple kinds in same subscription:

plugin: azure.azcollection.azure_rm
auth_source: auto
include_vm_resource_groups: [] # ignore azure vm
include_hcivm_resource_groups: ['*']
include_arc_resource_groups: ['*']

this also works if i show azure vms, but this would pollute my sample with too many entries^^
note that include_arc_resource_groups is mandatory as the default is [] (none)

i get this output with this PR + the fix i mentionned