Retrive vmware virtual machine MAC address for host association

chaoyangc · July 19, 2022, 3:15pm

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:

lstejskal · July 20, 2022, 7:10am

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:

chaoyangc · July 20, 2022, 12:41pm

Thank you @lstejskal
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!

lstejskal · July 21, 2022, 6:48am

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

ezr-ondrej · July 21, 2022, 7:19am

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

github.com

theforeman/foreman/blob/4ea1a6b709e3755aa6bd0eb76754f34b56797197/app/models/compute_resources/foreman/model/vmware.rb#L53

    
      
          end
          
          
def supports_update?
            true
          end
          
          
def capabilities
            [:build, :image]
          end
          
          
def vms(opts = {})
            if opts[:eager_loading] == true
              super(datacenter: datacenter)
            else
              # VMware server loading is very slow
              # not using FOG models directly to save the time
              # and minimize the amount of time required (as we don't require all attributes by default when listing)
              FogExtensions::Vsphere::MiniServers.new(client, datacenter)
            end
          end

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