Standalone ESXi discovery

  • Release version: Washingtondc
  • Updated February 1, 2024
  • 6 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Standalone ESXi Discovery

    Standalone ESXi discovery enables the identification of individual ESXi servers that manage virtual machines (VMs) without requiring a vCenter. This process involves scheduling discovery to automatically collect various configuration items (CIs) and their relationships.

    Show full answer Show less

    Key Features

    • Role Requirements: Users must have the itil, asset, and discoveryadmin roles to access ESXi CI records and execute the discovery.
    • VMware Credentials: Necessary to run the discovery, credentials can be created in the Discovery > Credentials > VMware Credentials section, using a domain account if needed.
    • Discovery Plugin: Ensure the Discovery plugin (com.snc.discovery) is installed and activated, and your system is upgraded to Washington DC or later.
    • Discovery Schedule: Create a new schedule for the ESXi host using its IP address, and activate the ESXi trigger probe.

    Key Outcomes

    By utilizing standalone ESXi discovery, customers can:

    • Identify ESXi servers through unique identifiers such as BIOS UUID and Managed Object Reference ID (MORID).
    • Collect comprehensive data about the ESXi environment, including server hardware, VMs, storage, and network components.
    • Manage resource pools, including the hidden root resource pool, enhancing visibility into resource allocation.
    • Easily transition from standalone to vCenter discovery, with automated processes to retire duplicate CIs from previous discoveries.

    Note that if an ESXi server is migrated to vCenter, triggering standalone discovery on that server will result in an error, ensuring data integrity.

    Standalone ESXi discovery supports discovery of individual ESXi servers that host virtual machines (VMs) and related components without a vCenter. Various CIs and relationships are discovered as part of a discovery schedule.

    Required roles

    Users with the itil and asset roles can access ESXi configuration item (CI) records. To run a standalone ESXi discovery, users must have the discovery_admin role.

    VMware credentials

    To run a standalone ESXi discovery, you need VMware credentials. Create the credentials by navigating to Discovery > Credentials > VMware Credentials.

    If you use a domain account to access the ESXi host, specify the domain with the user name in the credential record in one of the supported formats, such as Domain\UserName.

    Note:
    The VMware credentials must have read-only role in the ESXi host.

    Requirements

    • Make sure the Discovery (com.snc.discovery) plugin is installed and activated and that you have upgraded to Washington DC or later.
    • Activate the ESXi trigger probe. Navigate to the Trigger Probe [trigger_probe_m2m] table. The esxi record is inactive by default. Mark Active as true to enable Standalone ESXi discovery.
    • Create a new Discovery schedule for the host with the appropriate IP address of the ESXi host.
    Note:
    If both SSH and ESXi are triggered, SSH is launched first and may cause Discovery to complete with the message "ESX Discovery is only supported through the vCenter." In this case, open the Unix - Classify probe and set ESX - OS inactive.

    ESXi server Discovery components

    Discovery identifies ESXi servers based on the correlation ID (BIOS UUID), when the hardware manufacturer is on a certified inclusion list. If the manufacturer is on the list, the correlation ID must be unique. If the manufacturer is not on the certified inclusion list, the Managed Object Reference ID (MORID) and Serial Number are checked as well.

    After Shazzam runs, it checks for the port probe esxi. Discovery then launches the VMWare - Standalone ESXi Server probe, which then launches the probes that explore the ESXi server. Other existing Discovery probes are also launched. For the complete list of probes, see List of Discovery probes.

    Table 1. ESXi server Discovery components
    Component Name Description
    IP Service ESXi IP Service ESXi - VMWare VM console is defined for the Port 902.
    Port Probe esxi ESXi Server Appliance web user interface. It is triggered by the IP Service ESXi and it triggers the probe VMWare - Standalone ESXi Server.
    Probe VMWare - Standalone ESXi Server Probe to get information about an ESXi server.
    Probe VMWare - vCenter ESX Hosts Creates records for ESXi servers and host mounts. Triggers other probes.
    • VMware - vCenter ESX Hosts Storage
    • VMware - vCenter Datastores
    • VMware - vCenter Networks
    • VMware -vCenter VMs
    Probe VMWare - vCenter ESX Hosts Storage Creates records for ESXi host hardware: network adapters, disks, HBAs, FC ports, iSCSI and FC disks. Creates relationships between DAS/iSCSI/FC disks and datastore disks.

    Basic server data from ESXi hosts is collected by the VMware - vCenter ESX Hosts probe.

    ESXi Standalone server data

    Discovery uses multiple existing probes to collect this data from ESXi. The data is saved in various tables. Some of the CIs which have the "server" field have a reference to ESXi Host (for example, cmdb_ci_esx_server).

    Table 2. VMware Virtual Machine Instance [cmdb_ci_vmware_instance]
    Field label Column name
    Name name
    Memory (MB) memory
    CPUs cpus
    Disks disks
    Network adapters nics
    Object ID object_id
    Server server
    State state
    Correlation ID correlation_id
    VM Instance UUID vm_instance_uuid
    Status install_status
    Table 3. VMware vCenter Datastore [cmdb_ci_vcenter_datastore]
    Field label Column name
    Name name
    Capacity (GB) capacity
    Free space (GB) freespace
    Accessible accessible
    Type type
    Object ID object_id
    Server server
    URL url
    Status install_status
    Table 4. VMware vCenter Network [cmdb_ci_vcenter_network]
    Field label Column name
    Name name
    Object ID object_id
    Server server
    Status install_status
    Table 5. VMware Network Adapter [cmdb_ci_vmware_nic]
    Field label Column name
    Name name
    MAC Address mac_address
    IP Address ip_address
    Netmask netmask
    Configuration Item cmdb_ci
    Object ID object_id
    Mac manufacturer mac_manufacturer
    DHCP Enabled dhcp_enabled
    Status install_status
    Table 6. VMware Datastore HostMount [vcenter_datastore_hostmount]
    Field label Column name
    VMware vCenter Datastore datastore
    ESX Server esx_server
    Accessible accessible
    Access Mode access_mode
    Table 7. Datastore Disk [cmdb_ci_vcenter_datastore_disk]
    Field label Column name
    Name name
    Manufacturer manufacturer
    Location location
    Description short_description
    Class sys_class_name
    Updated sys_updated_on
    Maintenance schedule maintenance_schedule
    Correlation ID correlation_id
    Datastore datastore
    Status install_status
    Table 8. ESX Resource Pool [cmdb_ci_esx_resource_pool]
    Field label Column name
    Name name
    CPU reserved (MHz) cpu_reserved_mhz
    CPU limit (MHz) cpu_limit_mhz
    CPU shares cpu_shares
    Memory reserved (MB) mem_reserved_mb
    Memory limit (MB) mem_limit_mb
    Memory shares mem_shares
    Object ID object_id
    Server server
    Managed object reference ID morid
    Status install_status
    Table 9. ESX Server [cmdb_ci_esx_server]
    Field label Column name
    Name name
    Manufacturer manufacturer
    Model ID model_id
    Operating System os
    OS Version os_version
    Description short_description
    Class sys_class_name
    Status install_status
    Table 10. Network Adapter [cmdb_ci_network_adapter]
    Field label Column name
    Name name
    Mac Address mac_address
    Netmask netmask
    Configuration Item cmdb_ci
    Mac manufacturer mac_manufacturer
    DHCP Enabled dhcp_enabled
    Status install_status
    Table 11. Disk [cmdb_ci_disk]
    Field label Column name
    Name name
    Computer computer
    Size size
    Manufacturer manufacturer
    Model ID model_id
    Status install_status
    Table 12. Storage HBA [cmdb_ci_storage_hba]
    Field label Column name
    Name name
    Model ID model_id
    Computer computer
    WWNN wwnn
    Status install_status
    Table 13. Fibre Channel Port [cmdb_ci_fc_port]
    Field label Column name
    Name name
    WWNN wwnn
    WWPN wwpn
    Speed speed
    Controller controller
    Computer computer
    Status install_status
    Table 14. iSCSI Disk [cmdb_ci_iscsi_disk]
    Field label Column name
    Name name
    Computer computer
    Size size
    Provided by provided_by
    IQN iqn
    Device LUN device_lun
    Storage type storage_type
    Status install_status
    Table 15. Fibre Channel Disk [cmdb_ci_fc_disk]
    Field label Column name
    Name name
    Computer computer
    Size size
    Provided by provided_by
    Device LUN device_lun
    WWN wwn
    Status install_status
    Table 16. IP Address [cmdb_ci_ip_address]
    Field label Column name
    IP Address ip_address
    IP version ip_version
    Netmask netmask
    Nic nic
    Status install_status

    Relationships

    Figure 1. Standalone ESXi discovery relationships
    Flowchart of standalone ESXi discovery relationships

    Resource pools

    Standalone ESXi discovery also fetches the resource pools on the host including the root resource pool. This root resource pool is always hidden for every ESXi host. The root resource pool may not be visible in the VSphere web client for the ESXi host, but you can view it using the mob browser.

    Navigate to this URL: <domain name/or ip_address>/mob/?moid=ha-root-pool

    The root resource pool groups the resources of that host. Other child resource pools can also be created from the root resource pool. The root is identified in the ESXi host with the Managed Object ID: ha-root-pool.

    Forward migration

    If you were using standalone ESXi discovery and now the same ESXi is part of vCenter, you can use vCenter discovery instead. Create a vCenter discovery schedule and trigger it. Triggering a vCenter discovery creates duplicate CIs in the following tables as the identifiers for the CIs are different when ESXi is standalone or part of vCenter:

    • VMware VCenter Network [cmdb_ci_vcenter_network]
    • ESX Resource Pool [cmdb_ci_esx_resource_pool]
    • VMware VCenter Datastore [cmdb_ci_vcenter_datastore]
    • Datastore Disk [cmdb_ci_vcenter_datastore_disk]
    To avoid duplicates, you must mark the CIs created by standalone ESXi discovery in the above four tables as retired. When vCenter discovery is triggered, the vCenterESXHostsSensor script include checks for all the ESXi servers whether they were previously discovered as standalone ESXi server. If yes, it automatically triggers the ESXMigrationUtil script to mark all the previously discovered duplicate CIs as retired.
    Note:
    If you want to trigger migration manually, you can do so by executing the following script from the background script: // @params esx_sys_ids – array of sys ids of all the ESXi servers which need to be migrated. 
    ESXMigrationUtil. retireCIsForESXForwardMigration(esx_sys_ids)

    Once an ESXi server is migrated to vCenter, triggering a standalone ESXi discovery schedule on the same ESXi host will result in an error. Discovery will be aborted with an error message that “This ESXi is part of vCenter <IP_address of Vcenter> discovery schedule. Aborting discovery”.