Retrive vmware virtual machine MAC address for host association

Problem:
We would like to import and associate host with compute resource (vmware) virtual machines and MAC address seems to be the key to be matched. However, with the “Show a virtual machine API” (/api/compute_resources/:id/available_virtual_machines/:vm_id), the mac_addresses attribute showing empty {} and hammer command also did not provide any MAC address information.
The MAC address information of a virtual machine can only be found from the UI. We need some way to process those programmatically. Any help would be much appreciated! thanks!

Expected outcome:
Get the MAC address information with hammer command or API
Foreman and Proxy versions:
Foreman 3.3 / Katello 4.5
Foreman and Proxy plugin versions:

Distribution and version:

Other relevant data:

I can confirm the issue, there is a discrepancy between the information shown in UI and API.

hammer compute-resource virtual-machine info --id CR_ID --vm-id WM_VM_ID

Id:               VM-ID
Name:             Abj-Satellite67
CPUs:             4
Memory:           8192
Power Status:     poweredOn
Host Name:        <HOSTNAME>
Hardware Version: vmx-14
Path:             /...
Operating System: Red Hat Enterprise Linux 7 (64-bit

Created issue for it:

Thank you @lstejska
In the meantime, do you happen to know where is this cache information stored? I could not find any information in the database. so I assume it’s store somewhere in a file. perhaps, the data can be access somehow. Thanks a again!

TBH I don’t know but I’m curious too, @ezr-ondrej - by the chance do you now where is the cache information stored?

Oh my… that souds quite bad, there is a cache in the compute resource model, that gets cached into the configured cache, you can configure this in /etc/foreman/settings.yaml and it caches to a file by default.

Tho that doesn’t seem to be the core issue at this case, I’d guess the reason for this is some optimalizations of loading the VMs we are doing in

So once the information gets through our optimized loader and once through non-optimized and probably some optimalizations weren’t perfect…