Host node

A Host node represents a general purpose computer on the network; any physical or virtual computer system in your organization. A host is of a specific type, such as a server or a desktop which BMC Discovery gains high quality interactive access to. A host is not an IP-connected device, such as a switch or a router.

The attributes of a Host node contain stable information about the host, such as processor and memory details, its primary host name, OS information, whether it is virtual, and so forth. Hosts are considered inferred information because rules inside the reasoning engine are used to determine which hosts exist based on the DiscoveryAccess results obtained. Hosts will only be created for discovery targets that should be considered hosts, as opposed to switches, printers or other infrastructure.

Host node lifecycle

The following section describes the scenarios in which a Host node is created, updated or destroyed automatically.

Creation/update

In order to maintain the model of hosts in the environment, BMC Discovery identifies hosts using an internal weighting algorithm, see Uniquely Identifying a Host for more information. Hosts are identified by a number of criteria using this algorithm. The creation, update and removal of a Host node are based on these identities.

A Host node is created in the datastore when a new host is inferred from a successful discovery. A Host is only created when good quality access to the target computer has been established. Good quality access is necessary for the BMC Discovery internal system to establish that there is sufficient stable information available to identify a Host. Stable information is considered to be data such as hardware details, how many active interfaces there are, bios serial numbers and so forth.

A Host node is not created unless information is available from the getDeviceInfo, getHostInfo. The getMACAddresses method must also be successful except in the case where vCenter is scanned using vSphere.

For as long as BMC Discovery's host identification algorithm can determine that a particular discovery target corresponds to a particular Host node, the Host node is updated every time the target is scanned on any of its IP addresses. Once a Host node is created, BMC Discovery will update its attributes as the host changes over time, while still retaining the original Host node and key.

When a Host node is first created, BMC Discovery constructs a key attribute that uniquely identifies the host. The key is based on a combination of attribute values from the Host, but those attributes can change over time. As the host is rescanned, the Host node attributes that contributed to the key can all change, but the key itself will not be changed. If a Host node is destroyed and then the corresponding host is rescanned, a new Host node will be created. If the attribute values that were originally used to construct the key have not changed, the new Host node will be given the same key as the original one, but if any of the attributes have changed, the new Host node will have a different key to the old one.

Removal

Host node can be destroyed either manually or automatically.

To remove a host node manually, find the host, select it in the list and pick Destroy from the Actions list.

By default, a Host node will be automatically destroyed, if BOTH of the following circumstances are fulfilled:

• No update has been made in ten days from any of the IP addresses known for this host.
• No update has been made in the last seven scans on the IP address currently being scanned.

Thus, if a host is not successfully scanned, by default, the Host node representing it will remain in the model for at least 10 days. In this context, "seen" means anything other than no update. The table below shows the default removal criteria for the Host node.

These are the default settings for the number of days and number of scans. You can change these settings on the Model Maintenance page. See Configuring-model-maintenance-settings for more information.

When a node with attachments is destroyed, the attachments are not destroyed, and remain attached to the destroyed node. See Attachments for an introduction to attachments.
If a host node is destroyed from the datastore, all of its relationships are destroyed as well. For example, a host might have a relationship to a location. If the host is destroyed, the relationship to that location will also be destroyed. See How-nodes-are-removed.

Uniquely Identifying a Host

There is no single identifying attribute that can be used reliably to identify hosts. BMC Discovery determines host identities using an internal host identification algorithm to select which existing Host node should be connected, if any, with the Directly Discovered Data from the current scan.

A Host node is only created or updated when BMC Discovery has enough information to determine that a suitable Host node does not already exist or that an existing Host node is the one to use. A host will not be created or updated unless BMC Discovery has working credentials to extract enough information from the host.

Once BMC Discovery has sufficient information on the scanned endpoint it searches in the datastore for candidate Host nodes to be updated. This is carried out using a series of search queries, for example:

• Host previously updated via a scan from this endpoint.
• Host with one of its IP addresses being the endpoint scanned.
• Host with the same bios serial number as the scanned endpoint.

The Host nodes returned by these, and other searches, are candidates for being linked with the scanned Discovery Access node.

All the candidates are then ranked using the BMC Discovery algorithm based on the data on the candidate and the data currently retrieved from the endpoint. Each attribute on the host could be one of the following:

• Confirmed - same attribute key, same value.
• Changed - the value on the host for that attribute key is different from the value scanned.
• Absent - the value is set on the candidate, but is no longer available in the scanned data.

For each attribute a score is set for confirmed, changed or absent values. These scores are then added together to build the ranking. The score for all the attributes are then added together.

Once all the candidates have been evaluated, Host nodes with a negative ranking are ignored, and the highest positive-ranked Host node will be chosen. If no Host nodes have a positive score, or if no candidates have been found, a new Host node is created. In all cases, the Host node is then updated with the new data.

Endpoint identity

BMC Discovery scans IP addresses, or endpoints. It is the job of the Host identification algorithm to match endpoints to Host nodes. When an endpoint is scanned, the host identification algorithm sometimes decides that the endpoint now corresponds to a different Host node to the previous scan of that endpoint. This can happen for three main reasons:

1. IP addresses have been reassigned so the endpoint really does correspond to a different host.
2. The endpoint still corresponds to the same host, but the host has changed so much since the previous scan that BMC Discovery cannot tell that it is the same one.
3. The endpoint still corresponds to the same host, but BMC Discovery's access credentials have changed substantially, meaning the data appears very different. This can happen when switching between SNMP and login access, for example.

All three situations look the same from BMC Discovery's point of view — the discovered data is significantly different from the data previously retrieved from the endpoint. To facilitate understanding of these scenarios, BMC Discovery creates an EndpointIdentity relationship between the Host nodes. The Host view displays the relationship and allows comparison of the new and old Host nodes.

In all situations, BMC Discovery will ultimately resolve the condition. If the change is due to an IP address reassignment, the original Host can be found by scanning a different endpoint. If that happens, the Host is connected to the new endpoint and the EndpointIdentity relationship is removed. In other situations, the original Host node will age out according to the normal ageing rules.

Virtualization and Consolidation

BMC Discovery performs consolidation of virtual and partitioned hosts. When it does this, the model it constructs is as follows:

• Virtual Hosts - see Virtual Hosts.
• Contained Hosts - see Contained Hosts.
• Clustered Hosts - see Clustered Hosts.

Virtual Hosts

Virtual Hosts are modeled so that the virtual host is related through the virtual machine to the physical host. For example:

• VMware Virtual Machines
• Solaris Containers 

Contained Hosts

Where a number of IP devices are discovered that are logical devices on hosts, they are modeled as shown in the diagram below. See Host node lifecycle.
For example, the following types of servers are treated in this manner:

• Sun Enterprise 10000 - E10K
• Sun Fire 12000 - F12K
• Sun Fire 15000 - F15K
• Sun Fire 20000 - F20K
• Sun Fire 25000 - F25K 

Clustered Hosts

Where a number of collaborative hosts are discovered (they are seen as individual IP devices and there is no parent), they are consolidated into clusters which are modeled as Cluster nodes, see Cluster node lifecycle. For example, the following types of cluster are treated in this manner:

• Microsoft Clusters
• Veritas Cluster Servers

Attributes of the Host node

The attributes of the Host node are described in the following table:

Relationships of the Host node

The relationships of the Host node are described in the following table: