When you add a VMware Compute Resource, any listed VMs appear to have an internally generated (to Satellite) UUID:

1. hammer host info --name=host.example.com | grep UUID
   UUID: 5020ffea-59f5-34fe-3642-66b7b8c7b532

The actual VM in vSphere will have a different VMware UUID. In this case: 4220b893-5c43-ff21-0a9c-77d7174a3a43.

For those of us who use external provisioning tools, once we've registered a VM with Satellite using subscription-manager, it would be trivial to be able to associate that VM with the host object in Satellite, except the UUID you use through the API isn't the vSphere one.

As per the logs:

2018-02-21 12:03:56 0a50b576 [app] [I] Started PUT "/compute_resources/2-SandBox/vms/5020ffea-59f5-34fe-3642-66b7b8c7b532/associate" for 10.18.41.225 at 2018-02-21 12:03:56 +0000
2018-02-21 12:03:56 0a50b576 [app] [I] Processing by ComputeResourcesVmsController#associate as HTML
2018-02-21 12:03:56 0a50b576 [app] [I] Parameters: {"authenticity_token"=>"xxxxxx", "compute_resource_id"=>"2-SandBox", "id"=>"5020ffea-59f5-34fe-3642-66b7b8c7b532"}

While I can imagine there are legitimate reasons for using an internal UUID instead of the one provided by VMware, it would be very useful for us to be able to perform a lookup to match the Satellite UUID with the vSphere UUID, and the easiest way for doing this is for Satellite to expose that information through the API somehow.