Unsupported content

 

This version of the product is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Discovering ESX and ESXi hosts

BMC Discovery enables you to discover the ESX and ESXi hosts in your environment. The preferred way of discovering ESX and ESXi hosts is via VMware vCenter.  When a VMware vCenter server or appliance is found and a valid vCenter credential is available, BMC Discovery retrieves a list of managed ESX and ESXi hosts. This requires valid vCenter credential if the VMware vCenter server or appliance was discovered with an SNMP or a Windows credential. The IP addresses of these hosts are added, as part of the same scan range, to the list of IP addresses that are going to be scanned. BMC Discovery uses the vSphere API to discover VMware ESX and ESXi hosts.  

The following credential types may be used to discover ESX and ESXi hosts:

  • vCenter credentials—used to to access a vCenter server using the vSphere API. The vCenter server  then communicates with the ESX/ESXi hosts. 

  • vSphere credentialsused to access ESX/ESXi hosts directly using the vSphere API.

  • ssh credentials—used to log in to individual ESX/ESXi hosts.

  • vSphere Web API with token authentication credentials—used to return tags applied to the virtual machine from the vCenter server. Discovery of tags from vCenter was introduced in the November 2019 TKU


Unpatched VMware vSphere known problems

Unpatched versions of VMware vSphere have known issues when scanned by various tools. We recommend that you apply the appropriate patches to affected systems. For more information about this issue, see the related information on Configipedia.

There are two ways of scanning a VMware ESX or ESXi host:

  • Indirect scanning
  • Direct scanning

Indirect scanning

BMC Discovery scans an IP address:

  1. The scan detects a Windows host running a vCenter server, or a vCenter appliance, using one of the credential types mentioned above.
  2. If vCenter credentials are defined, they are used to connect to the vCenter server on port 443. 

  3. On successful connection, BMC Discovery retrieves a list of ESX and ESXi hosts managed by a VMware vCenter server.
  4. If you have supplied an additional vSphere Web API with token authentication credential, the tags for each virtual machine are also returned. Discovery of tags from vCenter was introduced in the November 2019 TKU
  5. The IP addresses are added to the list of IP addresses that were specified in the original scan. As they are not requested by a user, they are referred to as implicitly scanned IP addresses.

If there are user requested IP addresses being scanned or waiting to be scanned, discovery waits until the implicit scan of IP addresses is complete, or there are no more IP addresses to scan. The IP address is removed, and the DroppedEndpoints node associated with the DiscoveryRun records OptAlreadyProcessing as the reason for removal.

Implicitly scanned IP addresses

When IP addresses are implicitly scanned, the DiscoveryRun records the total number of IP addresses as usual, but it also records counts of IP addresses whose scan was requested by a user (explicit_ip_count) and implicitly scanned (implicit_ip_count) IP addresses.

The following screenshot shows an idirectly scanned discovered VMware ESXi host:

Direct scanning

BMC Discovery scans an IP address:

  1. The scan detects the following:
    1. Port 902 is open and responds to a vSphere API call with a message from the VMware Authentication Daemon.
    2. Port 443 (HTTPS) is open.
    3. Valid vSphere credentials are available.

  2. BMC Discovery uses the vSphere API on port 443 to discover the ESX/ESXi host. However, if the host has already been discovered via vCenter, then the discovery attempt is terminated, and the DiscoveryAccess node records OptNotBestAccessMethod as the reason for failure.
  3. If the discovery attempt using vSphere is unsuccessful, and port 22 or an alternative ssh port is configured, an ssh discovery is attempted.

The following screenshot shows a directly scanned discovered VMware ESXi host:

Supported versions

VMware ESX and ESXi discovery uses version 2.5 of the  vSphere API Open link , which supports the following versions and later:

  • ESX 3.5
  • ESXi 3.5
  • vCenter Server 4.0
  • VirtualCenter 2.5

Required vSphere privileges

The minimum privilege required to use the vSphere API for discovery is the System.View privilege. This is given by default to all users who can log in, including read only users.

Pattern-specific privileges (for VMwareVM.VMwareVSphereLicenseDetail pattern)

Some patterns, such as the VMwareVM.VMwareVSphereLicenseDetail pattern require additional privileges to gain complete information. This pattern requires access using a credential with the Global.Licenses privilege. Without this, the license key information is either partially (if discovered using vCenter) or fully (if discovered via vSphere) redacted.

Privilege and discovery method

Returned key information

With Global.Licenses privilege

30DCK-DUMMY-KEY!!-DUMMY-911F0

vCenter with System.View privilege

30DCK-#####-#####-#####-911F0

Direct (vSphere) with System.View privilege

XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

The same information is returned by the VMware client when accessing the target using the same methods and privileges.

Intermittent retrieval of vCenter serial number (ServiceTag) 

vCenter caches the serial number (ServiceTag) value in memory rather than in its database. That cache expires after some time. Therefore, if you look at the ESX host via the vSphere client or the managed object browser, or perform a scan while the cached value is held in memory, you see the ServiceTag value, and BMC Discovery retrieves it. After the value has expired, the only way to get it back is to restart the ESX host services. This behavior will only be fixed in an upcoming major vSphere release. You can view related discussions on the BMC Discovery community forum.

SSH discovery of VMware ESX and ESXi hosts

SSH discovery of ESX and ESXi hosts is a fallback method used when other methods have been unsuccessful. If ssh access has not been enabled, the ESX or ESXi system is not discovered.

VMware ESX and ESXi ssh discovery requires a root user permissions

VMware ESX and ESXi ssh discovery requires root user permissions. You must log in directly as the root user. It is possible to log in as a nonroot user, but such a user cannot close sessions properly. This results in sessions hanging and inactive sessions building up on the ESXi host.

VMware ESX and ESXi discovery limitation

VMware ESX and ESXi ssh discovery cannot determine network connection details, because the netstat command has no equivalent.

Related topics

Was this page helpful? Yes No Submitting... Thank you

Comments