I was browsing through the vSphere API Reference the other day and I came across an interesting vSphere API called QueryConnectionInfoViaSpec() which was introduced in vSphere 6.0. This new API is similiar to the existing QueryConnectionInfo() method which also allows you to remotely query an ESXi host without requiring you to add it to your vCenter Server Inventory, which I did not know about before. Some of the information that you can retrieve is whether it is currently being managed by an existing vCenter Server and if so, what is its IP Address, any registered Virtual Machines, networks and datastores that may be configured along with underlying host capabilities.
The main difference between this new API is that instead of accepting a list of arguments to the method, it accepts a HostConnectSpec. It is a minor difference, but what this allows you to do is to be able to re-use that exact same spec in the AddHost_Task() API if you determine that you would like to add the ESXi host to your vCenter Server Inventory after inspecting the remote ESXi host. I think this is a useful API if you want to validate that you are not stealing an ESXi host from another managed vCenter Server and if you are, at least you know which vCenter Server it was being managed by. To demonstrate this vSphere API, I have created a simple PowerCLI script called Get-RemoteESXi.ps1 which requires a vCenter Server login as well as the Hostname/IP Address and credentials of the remote ESXi host you wish to query.
Here is an example output of running the script which stores the returned output to the $results variable.
If you want to check whether the ESXi host is being managed by an existing vCenter Server, you can check the following property which will hold the IP Address of the vCenter Server if it is currently being managed:
$result.Host.ManagementServerIp
If you want to check if there are running VMs already on the ESXi host, you can check the following property:
$result.vm
As mentioned earlier, there is a ton of other information returned from the remote ESXi host and I will leave it as an exercise for the reader to explore further.