Discovering ESX and ESXi hosts
BMC Helix 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 Helix Discovery retrieves a list of managed ESX and ESXi hosts. This requires a 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 Helix 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 access a vCenter server using the vSphere API. The vCenter server then communicates with the ESX/ESXi hosts.
vSphere credentials—used 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.
Warning
Unpatched versions of VMware vSphere have known issues when scanned by various tools. We recommend that you apply the appropriate patches to the affected systems. For more information about this issue, see the related information on BMC Discovery content reference .
There are two ways of scanning a VMware ESX or ESXi host:
- Indirect scanning
- Direct scanning
Indirect scanning
BMC Helix Discovery scans an IP address:
The scan detects a Windows host running a vCenter server, or a vCenter appliance, using one of the credential types mentioned above.
If vCenter credentials are defined, they are used to connect to the vCenter server on port 443.
- On a successful connection, BMC Helix Discovery retrieves a list of ESX and ESXi hosts managed by a VMware vCenter server.
- 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.
- 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.
Required vCenter privileges
The minimum privileges required for full discovery of ESXi hosts using vCenter credentials are listed below:
Managed Object Type: | |
---|---|
hardware.systemInfo.uuid | config.network.pnic |
name | config.network.vnic |
runtime.connectionState | config.virtualNicManagerInfo.netConfig |
config.network.consoleVnic | |
Managed Object Type: | |
config.alternateGuestName | guest.guestFullName |
config.guestFullName | guest.guestId |
config.guestId | guest.hostName |
config.name | guest.ipAddress |
config.template | name |
config.tools.toolsVersion | runtime.powerState |
config.uuid |
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 indirectly scanned discovered VMware ESXi host:
Direct scanning
BMC Helix Discovery scans an IP address:
- The scan detects the following:
- Port 902 is open and responds to a vSphere API call with a message from the VMware Authentication Daemon.
- Port 443 (HTTPS) is open.
Valid vSphere credentials are available.
- BMC Helix 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. - 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 use version 2.5 of the vSphere API , 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 |
|
vCenter with |
|
Direct (vSphere) with |
|
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 Helix 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 Helix Discovery community forum.
vCenter server incorrectly reports completion of VM migration
Occasionally, a vCenter server may incorrectly report that a VM migration has been completed, even though the migration failed. In the BMC Discovery model, the SI representing the VM is moved to a different ESXi host, when in fact the migration failed. However, at the next scan, the SI will be correctly relocated.
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 root user permissions
VMware ESX and ESXi ssh discovery require root user permissions. You must log in directly as the root user. It is possible to log in as a non-root user, but such a user cannot close sessions properly. This results in session 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.
Comments
Log in or register to comment.