Default language.

Important This documentation space contains information about the SaaS version of BMC Helix Discovery. If you are using the on-premises version of BMC Helix Discovery, see BMC Helix Discovery 25.2 (On-Premises).

CDM Mapping for Storage

This topic provides information about mapping for storage. The CIs created are described in this topic.

Data models

Note

The default mapping works with CMDB versions 7.5, 7.6, and 7.6.03 and later. The data model in each is slightly different.

  • BMC_Impact relationships are not normally created with CMDB 7.6.03 and later, since the CMDB automatically maintains them itself. See the information about impact relationships for more details.


Click here for reference information on impact and the data models.

Different versions of the CMDB have subtly different data models. Syncmappings can support multiple data models with datamodel declarations. CMDB data models are assigned simple integer values:

The mappings performed during CMDB-synchronization are specified in syncmapping blocks in TPL. A syncmapping is similar to a pattern, but it triggers from a queued synchronization action, rather than from data being updated in the data store.

The form of a syncmapping is:

syncmapping name version
 description
 overview
   overview_entries
 end overview;
 [constants
   constant_definitions
 end constants;]
 mapping mapping_source as source_name
   mapping_definitions
 end mapping;
 body
   body_details
 end body;
end syncmapping;

As with pattern blocks, the name, version, and description are mandatory.

Pattern-templates are provided to help you create your own syncmappings.

Overview section

The overview is required. It contains information about the pattern and the entities it creates. It must contain a tags entry, and can have an optional datamodel entry, as described in Data models.

The overview section can also have an optional overrides entry, which enables you to change the behavior of an existing mapping and to preserve those changes on subsequent TKU updates to the overridden mapping. Non-syncmapping patterns have an "overridden" flag displayed on the pattern management page, syncmappings do not.

Here is an excerpt from an overriding mapping:

...
*from* CMDB.Host_ComputerSystem *import* Host_ComputerSystem 1.2;
*from* CMDB.SoftwareInstance_SoftwareServer *import* SoftwareInstance_SoftwareServer 3.2;
// The mapping referred to by the overrides keyword must be imported

*syncmapping* SoftwareInstance_SoftwareServer_override 3.2
   """
   Example override mapping.
   """
   *overview*
       *tags* CMDB, Core_Mapping;
       *datamodel* 0, 1, 2, 3, 4, 5, 6;
       *overrides* SoftwareInstance_SoftwareServer;  // The overridden pattern is imported above
   *end* *overview*;

   *mapping* *from* Host_ComputerSystem.host *as* host
       *traverse* Host:HostedSoftware::SoftwareInstance *as* si_node

           *traverse* Element:Maintainer:Pattern:Pattern *as* si_pattern
           *end* *traverse*;
...

Note

The mapping referred to by the overrides keyword must be imported. All definitions from the original mapping section such as node kinds, traversals and names must be preserved. It is possible to add additional traversals and names in the overriding mapping.

Mapping section

The mapping section declares the starting point for the mapping, the structure of source data retrieved from the Discovery model, and the target CIs created in the CMDB model. It does not describe how the source data is transformed to the target model — that is performed in the body section.

Mapping source

Each mapping is either a root mapping, meaning that it is invoked by the synchronization of a single root node with the corresponding kind, or an extension mapping, meaning that it extends another mapping at a suitable point.

You should not use DDD directly in mappings, rather, you should copy the required DDD into the inferred model first.

Root mappings have a mapping declaration using the on keyword:

*mapping* *on* _node_kind_ *as* _name_
 _mapping content..._
*end* *mapping*

For example, this specifies the root mapping for Host nodes:

*mapping* *on* Host *as* host_node

Extension mappings have a mapping declaration using the from keyword:

*mapping* *from* _source_scoped_name_ *as* _name_

For example:

*mapping* *from* ExampleMapping.host_node *as* host_node

The source_scoped_name is the name of a source mapping variable from another mapping block, either the source name specified in the mapping declaration, or a traversal name as described below.

Multiple "From" expressions in the mappings block

Multiple parent mappings are supported, by using more than one "From" expression in the mapping block, for example:

SoftwareInstance_SoftwareServer 4.0
...
    mapping from Host_ComputerSystem.host from Cluster.cluster as hosting_system
...

In this example the mapping input can be from a Host or a Cluster node in the (BMC Discovery model). All of the input parameters used in the mapping statement must have corresponding references in the body. An example in the case of the above mapping statement is:


hosting_ci := Cluster.cluster_ci or Host_ComputerSystem.computersystem;

The hosting system (in the CMDB model) is either a BMC_Cluster or a BMC_ComputerSystem. The order matters here; the interpreter takes the first defined object which it finds (checking from left to right).

Mapping traversals

The source subgraph is declared using traverse clauses inside the mapping with a syntax similar to traversals in search expressions:

*traverse* _traversal_specification_ *as* _nodename_
 _traversal contents..._
*end* *traverse*

The nodename defined by the traversal can only be used in a 

for each
 expression; it cannot be used in any other context.

You can also define a relationship relname for a traverse clause inside the mapping. The first is the name of the relationship and the second is the name of the node.

*traverse* _traversal_specification_ *as* _relname_, _nodename_
 _traversal contents..._
*end* *traverse*

In each case the relname and nodename defined by the traversal can only be used in a 

for each
 expression; they cannot be used in any other context. You can access the attributes on a relationship by using the name you assigned to the relationship followed by a dot and the attribute as specified in the syncmapping.

Where clauses

The initial source node and the results of traversals can be filtered with where clauses, specified before the as token. where clauses in mapping blocks use the same subset of search where clauses as trigger conditions in pattern blocks.

*mapping* *on* _node_kind_ *where* _condition_ *as* _name_

*mapping* *from* _source_scoped_name_ *where* _condition_ *as* _name_

*traverse* _traversal_specification_ *where* _condition_ *as* _name_

However, you cannot use search in a syncmapping.  CMDB synchronization takes a graph of connected nodes in BMC Helix Discovery and transforms them into a graph of connected CIs in the CMDB. If the where clause contains a search there is no guarantee of any such connection.

Target CI declarations

As the subgraph is processed in the body, target CIs are specified. The mapping block contains declarations of the CIs that are mapped, in the form:

_name_ *->* _CI_class_;

For example:

computersystem *->* BMC_ComputerSystem;

Targets are specified within the traversal structure. For example, part of the mapping of virtual machines is as follows:

*mapping* *from* Host_ComputerSystem.host *where* virtual *defined* *as* host
 *traverse* ContainedHost:HostContainment:HostContainer:SoftwareInstance *as* vm_si

   vse *->* BMC_VirtualSystemEnabler;

   *traverse* RunningSoftware:HostedSoftware:Host:Host *as* containing_host
     containing_cs *->* BMC_ComputerSystem;
   *end* *traverse*;
 *end* *traverse*;
*end* *mapping*;

Grouping

In some circumstances, a number of nodes in the Discovery model must be grouped together to construct a single CI in the CMDB model. This is declared in the mapping with a group block. The form of a group block is

*traverse* _traversal_specification_ *as* _traversal_name_
 *group* _group_name_
   _group contents..._
   *expand* *group* *as* _expansion_name_
     _expansion contents..._
   *end* *expand*;
 *end* *group*;
*end* *traverse*;

The declaration indicates that nodes from the containing traversal will be grouped together (according to rules specified in a group block in the body), and then the group will be expanded to the individual group members. The expand is not required if there is no need to process the individual nodes within the group.

Syncmapping body 

The body of a syncmapping is responsible for implementing the mapping described in the mapping block. The majority of language features and functions available in pattern body blocks are permitted, except that functions in the following namespaces are not available since they are only appropriate for patterns that perform discovery and construct the Discovery model.

  • discovery
  • inference
  • mail
  • model

Additionally, user-defined functions are not supported.

Any date/time fields should be passed as datetime objects rather than formatted datetime strings.

Body execution

The body of a syncmapping is executed at a time that depends upon the mapping source definition.

The body of a root mapping (specified with mapping on) is executed at the time the root node is scheduled for synchronization.

The body of an extension mapping (specified with mapping from) that extends the source node of another mapping is executed when the body of the extended mapping completes.

The body of an extension mapping that extends a traversed-to node of another mapping is executed each time the associated for each loop (see below) completes.

When a node in the Discovery data store is marked as destroyed, only the root mapping's body is executed, and the target root CI is scheduled for deletion in the CMDB. When the delete is synchronized with the CMDB, the root CI and all the related CIs previously created by the mapping are deleted. For best performance during deletion, root mappings should not perform any traversals or other time-consuming activities.

CI definition

CIs and relationships in the CMDB are specified with functions in the sync namespace similar to those in the model namespace used within pattern blocks.

Any CMDB class can be specified with a function call of the form

value := sync._BMC_ClassName_(key := _some_key_, _attributes..._);

Any class name can be specified. Specifying a class that is not defined in the CMDB results in a run-time error. The key attribute must be set, and is used to populate the ADDMIntegrationId attribute in the CMDB. Any other attribute name can be set; attributes that are not defined in the CI class are ignored.

The result of the function must be assigned to a target CI name specified in the mapping block. The class specified in the function must be the same as the one specified in the mapping or a subclass of it.

CI class namespaces

CMDB classes are assumed to be in the BMC.CORE namespace. To refer to a class in a different namespace, provide a namespace parameter to the function call:

value := sync._BMC_ClassName_(key := _some_key_, namespace := "My.NameSpace", _attributes..._);

The namespace must be a literal string — it cannot be constructed at runtime.

Shared CIs

The subgraph of data in the Discovery model is transformed into a subgraph of CIs in the target CMDB model. Most of the CIs belong to a single target subgraph, but some are shared by more than one subgraph. An example is the BMC_IPConnectivitySubnet CI that is shared by all the computers on a particular subnet. For deletion to work correctly, the system must know that such CIs are shared. This is achieved by calling the function in the sync.shared namespace:

value := sync.shared._BMC_SharedClassName_(key := _some_key_, _attributes..._);

External CIs

Similarly, it is sometimes necessary to specify a relationship to a CI that is not part of the target subgraph. An example is to relate the BMC_ComputerSystem for a physical host to the one for a virtual host — the two CIs belong to different subgraphs. External CIs are specified with a function in the sync.external namespace:

value := sync.external._BMC_ClassName_(key := _some_key_ _[, namespace := "_NAMESPACE_" ]);

The key must be specified, and namespace must be specified if required. No other attributes can be set.

It is not an error if a CI with the specified key does not exist in the CMDB. In that situation, the CI and any relationships to it are simply ignored.

Cross-reference CIs

As the mapping is processed, the CIs are specified in a tree traversal across the graph. To refer to a CI specified in a different branch of the tree, it can be specified with a function in the sync.crossref namespace:

value := sync.crossref._BMC_ClassName_(key := _some_key_ _[, namespace := "_NAMESPACE_" ]);

The key must be specified, and namespace must be specified if required. No other attributes can be set.

It is a runtime error to specify a cross-reference to a CI that is not fully specified elsewhere within the mapping.

TokenId rules

TokenId is an attribute that, in some circumstances, aids the reconciliation of CIs populated by multiple data sources. BMC Helix Discovery sets TokenId depending on the Node kind.

For most Nodes, TokenId is one of the forms:

key

or

ADDM:%key%

or

ADDM:%hashed_key%

For databases, TokenId is a database host found as a result of all possible combinations of where the database might be running:

%hosting_ci.TokenId%:%database_node.type%:%si_instance%:%database_node.instance%

and

%hosting_ci.Name%:%database_node.type%:%si_instance%:%database_node.instance%

For the Fibre Channel Node, TokenId is of the form:

WWN:%wwpn% 

For physical hosts, TokenId is of the form:

%host.hostname%:%host.dns_domain%

If the domain name is unavailable, then

%host.hostname%

For virtual hosts that are running in the cloud, TokenId contains instance_id.

  • For Alibaba, TokenId is of the form:
%alibaba_instance_id%
  • For Azure, TokenId is of the form:
%azure_vm_id%
  • For AWS, TokenId is of the form:
%aws_instance_id%
  • For GCP, TokenId is of the form:
%gce_instance_id%
  • For IBM, TokenId is of the form:
%instance_id%
  • For OCI, TokenId is of the form:
%ocid%

For virtual hosts that are running in the hypervisor, TokenId contains UUID.

  • For AHV, TokenId is of the form:
AHV-UUID:%uuid%
  • For Hyper-V, the UUID is only available on the physical machine, so TokenId is only set for virtual machines that have been successfully linked to their hosting physical machines:
HYPERV-ID:%vm_uuid%
  • For KVM (including RedHat Enterprise Virtualization), TokenId is of the form:
KVM-ID:%uuid%
  • For VMware, TokenId is of the form where each letter represents a hexadecimal digit:
VI-UUID:%uuid%
  • For Xen (including Oracle VM), TokenId is of the form: 
XEN-ID:%uuid%

The following table shows how TokenId looks like for different Node Kinds:

Node Kind

CI

TokenId

AdminCollection

BMC_AdminDomain

key

Cluster (cloud)

BMC_Cluster

key

LoadBalancerService

BMC_LogicalSystemComponent

ADDM:%key%

LoadBalancerPool

BMC_ResourcePool

ADDM:%key%

CloudManagementGroup

BMC_AdminDomain

cloud_id

CloudProvider

BMC_CloudInstance

key

CloudRegion

BMC_CloudInstance

key

CloudService

BMC_CloudInstance

key

Cluster

BMC_Cluster

ADDM:%hashed_key%

Database (cloud)

BMC_DataBase

ADDM:%key%

Database


BMC_DataBase


%hosting_ci.TokenId%:%database_node.type%:%si_instance%:%database_node.instance%
%hosting_ci.Name%:%database_node.type%:%si_instance%:%database_node.instance%

HardwareComponent

BMC_HardwareSystemComponent

ADDM:%hashed_key%

HardwareContainer

BMC_ComputerSystem

ADDM:%hashed_key%

HostContainer

BMC_ComputerSystem

ADDM:%hashed_key%

Host








BMC_ComputerSystem








%host.hostname%:%host.dns_domain%
%host.hostname%
ALIBABA-ID:%alibaba_instance_id%
AWS-ID:%aws_instance_id%
GCP-ID:%gce_instance_id%
IBM-ID:%instance_id%
OCI-ID:%ocid%
AZURE-ID:%azure_vm_id%
HYPERV-ID:%vm_uuid%
XEN-ID:%uuid%
KVM-UUID:%uuid%
AHV-UUID:%uuid%
VI-UUID:%uuid%

LoadBalancerGroup

BMC_Cluster

ADDM:%key%

MFPart

BMC_ComputerSystem

key

Namespace

BMC_AdminDomain

key

Deployment

BMC_ConcreteCollection

key

NetworkService

BMC_LogicalSystemComponent

ADDM:%key%

FibreChannelPort

BMC_NetworkPort

WWN:%wwpn%

SoftwareCluster

BMC_Cluster

ADDM:%hashed_key%

SoftwareComponent

BMC_ApplicationService

ADDM:%hashed_key%

SoftwareInstance

BMC_ApplicationSystem

ADDM:%hashed_key%

SoftwareInstance

BMC_SoftwareServer

ADDM:%hashed_key%

VirtualMachine

BMC_VirtualSystemEnabler

ADDM:%hashed_key%

StorageDevice

BMC_Cluster

ADDM:%key%

StoragePool

BMC_ResourcePool

ADDM:%key%

StorageSystemGroup

BMC_Cluster

ADDM:%key%

StorageProcessor

BMC_HardwarePackage

ADDM:%key%

HardwareContainer

BMC_HardwareSystemComponent

ADDM:%hashed_key%

Relationship definition

Relationships are specified with functions in the sync.rel namespace:

sync.rel._BMC_RelName_(Source := _source_val_,
                       Destination := _dest_val_, 
                       Name := "_RELNAME_" _[, ... ]_);

The first two parameters must be Source and Destination. Any other attributes can also be set; Name is not required, but it is conventionally always set.

The Impacted and ImpactWeight attributes can be used to create impact relationships. They specify impact direction and percentage respectively. For example, an ImpactWeight of 25 might be appropriate when representing an impact relationship between a BMC_ComputerSystem and BMC_Cluster, where there are four computers in a cluster. The value assigned to Impacted must be the Source or Destination CI appearing in the same definition.

sync.rel.BMC_Component(
   Source       := computersystem,
    Destination  := cluster_ci,
    Name         := "CLUSTEREDSYSTEM",
    Impacted     := cluster_ci,
    ImpactWeight := cluster_rel.impact_weight
);

Note that prior to tpl 1.10 multiple relationship definitions were needed to represent a single impact relationship in the CMDB. This was because the way in which impact is represented in the CMDB depends on the data model in effect (see below). In tpl 1.10 and later, only one definition is required.

Traversal looping

One of the main activities performed in the body is to iterate over the nodes reached through the traversals specified in the mapping block. A for each loop is used to iterate over the named nodes:

*for* *each* _source_node_ *do*
  ...
*end* *for*

The nesting structure of for each loops in the body must match the nesting structure of the traverse expressions in the mapping block.

A for each loop is required even if the corresponding traversal is expected to reach just one node. There is no other way to access the state of the traversed-to node.

Group block

When the mapping block specifies a group, there must be a corresponding group block in the body. The group block will always be inside a for each block, either directly within a single syncmapping body or in an extended source syncmapping.

A group block takes the form:

*for* *each* _traversed_to_node_ *do*
  ...
 ident := _group_identifier_;
 *group* _group_name_ *with* ident *do*
    ...

   *for* *each* _expand_name_ *do*
      ...
   *end* *for*;
 *end* *group*;
*end* *for*;

The grouping is evaluated in two phases. In the first phase, every iteration of the surrounding for each loop is executed. The nodes are grouped according to the identifier provided to the group expression. After all the iterations of the for each loop, the group block is executed once for each group. If the group declaration in the mapping block contains an expand declaration, there should be a corresponding for each loop in the body.

The group content is executed in a context based on an arbitrary member of the group. Any local variables from the surrounding loop will therefore be valid for a member of the group, but there is no guarantee that it will be the same group member each time a particular group is processed.

Data models

Different versions of the CMDB have subtly different data models. Syncmappings can support multiple data models with datamodel declarations. CMDB data models are assigned simple integer values:

Data model

CMDB versions

Effect

6

7.6.03 and later

HasImpact and ImpactDirection attributes are set as appropriate.

5

7.6.03 and later

Only to be used with legacy SIM version 7.4. BMC_Impact relationships with Name “ImpactOnly” are created.

4

7.6.03 and later

No impact details are set by BMC Discovery. They may be set by Impact Normalization in the CMDB.

3

7.6 before 7.6.03

BMC_Impact relationships with name “IMPACT” are created.

2

7.5

BMC_Impact relationships with name “IMPACT” are created.

A syncmapping can limit itself to a particular set of data models with a datamodel declaration in the overview:

*overview*
 *tags* Some_tags;
 *datamodel* 3, 4;  // Only CMDB 7.6.x
*end* *overview*

The body of a syncmapping can further modify its behavior for different data models with a datamodel block. The datamodel block only executes if the data model in effect matches the declaration:

ci := sync.BMC_Thing(key := my_key, ...);

*datamodel* 2, 3 *do*
   sync.rel.BMC_Dependency(
   Source      := ci,
   Destination := other_ci,
    Name        := "DEPENDENCY_NAME"
   );
*end* *datamodel*;

The data model in effect is not chosen automatically. After you configure CMDB synchronization, the data model is selected. This is described in Setting-up-a-CMDB-synchronization-connection.

BMC_ComputerSystem

The StorageSystem node is mapped to BMC_ComputerSystem CIs.

BMC_ComputerSystem

Attribute

Details

Name

StorageSystem name

ShortDescription

StorageSystem name

Description

StorageSystem name

CapabilityList

List of capabilities

Domain

The DNS domain reported by the StorageSystem.

EndOfExtendedSupport

End of Extended Support date.

EndOfLife

End of Life date.

EndOfSecuritySupport

End of Security Support date.

EndOfSupport

End of Support date.

ManufacturerName

StorageSystem vendor

Model

Model, of the form StorageSystem type:StorageSystem model.

Where the model and type of the storage system are the same, the model is set to the StorageSystem model.

isVirtual

True if the Storage System is virtual; not set if physical.

PrimaryCapability

Storage

SerialNumber

StorageSystem serial number

Category

The CDM category, for example, "Hardware".

Type

The CDM type, for example, "Disk device".

Item

The CDM item, for example, "Disk array".

BMC_ComputerSystem relationships

Populate the Company attribute for BMC_ComputerSystem CIs mapped from StorageSystem nodes.

Creates links to manager CI and sets LastScanDate and SystemOID where available.

Note

Do not create an extension syncmapping that extends this one. If you need to access nodes accessed in the traversals here, traverse again. This priority syncmapping must complete before any other CIs are created.


  • First-order Software Instances are mapped to BMC_SoftwareServer CIs.
  • Second-order Software Instances are mapped to BMC_ApplicationSystem CIs.

Relationship

Name

Source

Destination

BMC_Dependency
SYSTEMMANAGER
BMC_SoftwareServer
BMC_ComputerSystem
BMC_Dependency
SYSTEMMANAGER
BMC_ApplicationSystem
BMC_ComputerSystem
BMC_Dependency
SYSTEMMANAGER
BMC_SoftwareServer
BMC_ComputerSystem
BMC_Dependency
SYSTEMMANAGER
BMC_ApplicationSystem
BMC_ComputerSystem
BMC_Dependency
STORAGEUSE

BMC_ComputerSystem
Storage System

BMC_ComputerSystem
Consuming Host
Impacted

BMC_Dependency
STORAGEUSE

BMC_ComputerSystemBackend Storage System

BMC_ComputerSystemconsuming NAS host

BMC_Dependency
BACKENDSTORAGEUSE

BMC_ComputerSystem
Backend Storage System

BMC_ComputerSystem
Consuming Host
Impacted

BMC_Dependency
NETWORKLINK

BMC_ComputerSystem
Network Device (SAN Switch)

BMC_ComputerSystem
Storage System
Impacted

BMC_OperatingSystem

StorageSystem OS is mapped to BMC_OperatingSystem.

Attribute

Details

key

StorageSystem key,

Name

"%device.os_vendor% %device.os_type% %device.os_version%" or
StorageSystem name : hostname if the target is Remedyforce.

ShortDescription
"%device.os_type% %device.os_version%"
Description

"%device.os_vendor% %device.os_type% %device.os_version%" or
StorageSystem name : hostname if the target is Remedyforce.

BuildNumber

StorageSystem os_build

EndOfExtendedSupport

End of Extended Support date.

EndOfLife

End of Life date.

EndOfSecuritySupport

End of Security Support date.

EndOfSupport

End of Support date.

ManufacturerName

StorageSystem os_vendor

MarketVersion

StorageSystem os_version

Model

StorageSystem os_type

OSType

0 (Other)

VersionNumber

StorageSystem os_version

Company

StorageSystem Company

Category

"Software"

Type

"Operating System Software"

Item

"Storage Operating System"

BMC_OperatingSystem relationships

Relationship

Name

Source

Destination

BMC_Component
SYSTEMOS

BMC_ComputerSystem 
(Storage System)

BMC_OperatingSystem

BMC_ResourcePool

The StoragePool node is mapped to the BMC_ResourcePool CI.

BMC_ResourcePool

Attribute

Details

TokenId

TokenId is of the form "ADDM:StoragePool key".

See TokenId rules.

Name

StoragePool name or
StoragePool name : computer system name if the target is Remedyforce.

ShortDescription

StoragePool ID

Description

StoragePool name

AllocationUnits

"byte"

Capacity

StoragePool capacity

CurrentlyConsumedResource

StoragePool consumed capacity

Primordial

If the pool type is primordial, "Primordial"

ResourceType

32=Storage Volume

Company

StorageSystem Company

Category

"Hardware"

Type

"Storage"

Item

"Storage pool"

The StoragePoolContainer node is also mapped to the BMC_ResourcePool CI.

Attribute

Details

TokenId

TokenId is of the form "ADDM:StoragePoolContainer key".

See TokenId rules.

Name

StoragePoolContainer name or
StoragePoolContainer name : computer system name if the target is Remedyforce.

ShortDescription

StoragePoolContainer ID

Description

StoragePoolContainer name

AllocationUnits

"byte"

Capacity

StoragePoolContainer capacity

CurrentlyConsumedResource

StoragePoolContainer consumed capacity

Primordial

If the pool container type is primordial, "Primordial"

ResourceType

32=Storage Volume

Company

StorageSystem Company

Category

"Hardware"

Type

"Storage"

Item

"Storage pool"

BMC_ResourcePool relationships

Relationship

Name

Source

Destination

BMC_Component
HOSTEDRESOURCEPOOL

BMC_ComputerSystem 
(Storage System)

BMC_ResourcePool(impacted)

BMC_Dependency
VIRTUALSYSTEMOS
BMC_ResourcePool

BMC_ComputerSystem 
(Storage System)(Impacted)

BMC_Dependency
VIRTUALSYSTEMOS

BMC_ResourcePool(Storage Pool Container)

BMC_ComputerSystem 
(Storage System)(Impacted)

BMC_HardwarePackage

The StorageProcessor node is mapped to the BMC_HardwarePackage CI. Serial number attribute is added for StorageProcessor.

BMC_HardwarePackage

Attribute

Details

TokenId

TokenId is of the form "ADDM:StorageProcessor.key".

Name

StorageProcessor description or
StorageProcessor name : computersystem name if the target is Remedyforce.

ShortDescription

StorageProcessor identifier.

Description

StorageProcessor description.

ManufacturerName

StorageProcessor vendor.

Model

StorageProcessor model name.

Company

StorageProcessor company.

Serial

StorageProcessor serial number.

Category

"Hardware"

Type

"Storage"

Item

"Storage processor"

BMC_HardwarePackage relationships

Relationship

Name

Source

Destination

BMC_HostedSystemComponents
SYSTEMHARDWARE

BMC_ComputerSystem
(Storage System)

BMC_HardwarePackage

BMC_HardwareSystemComponent

StorageSystem linking to contained HardwareContainers.

BMC_HardwareSystemComponent

Attribute

Details

key

hardware_container.key

TokenId

TokenId is of the form "ADDM:HardwareContainer.key".

See TokenId rules.

Name

Hardware Container Name

ShortDescription

Hardware Container Name

Description

Hardware Container Name

EndOfExtendedSupport

End of Extended Support date.

EndOfLife

End of Life date.

EndOfSecuritySupport

End of Security Support date.

EndOfSupport

End of Support date.

ManufacturerName

Hardware Container Vendor

Model

Hardware Container Model

SerialNumber

Hardware Container Serial

Company

Company

Category

"Hardware"

Type

"Hardware"

Item

Hardware Container Serial type

Relationship

Name

Source

Destination

BMC_HostedSystemComponents
SYSTEMHARDWARE

BMC_ComputerSystem (Storage System)

BMC_HardwareSystemComponent

BMC_NetworkPort, BMC_IPEndpoint and BMC_LANEndpoint

Each Network Interface node connected to the root StorageSystem in the BMC Helix Discovery model is mapped to a BMC_NetworkPort CI, and its MAC address is mapped to a BMC_LANEndpoint CI. Each of its associated IP addresses are mapped to BMC_IPEndpoint CIs.

The IP addresses of a StorageSystemGroup are mapped to BMC_IPEndpoint CIs.

BMC_NetworkPort

Attribute

Details

Name

Interface name of the Network Interface

ShortDescription

Interface name of the Network Interface

Description

Full name of the Network Interface

AutoSense

Negotiation setting, 0=Yes, 1=No.

FullDuplex

Full duplex, 0=Yes, 1=No.

LinkTechnology

2. (Ethernet)

ManufacturerName

The Network Interface manufacturer

PermanentAddress

MAC address.

PortType

2. (Ethernet)

Speed

The interface speed in bps

Company

Network Interface Company

Category

"Hardware"

Type

"Card"

Item

"Network interface card"


The front-end FibreChannelPort is mapped to BMC_NetworkPort.

Note

Note that Fibre Channel is the correct spelling for the technology. Do not "correct" the Item to Fiber Channel.


Attribute

Details

TokenId

TokenId is of the form "World Wide Name:World Wide Port Number".

See TokenId rules.

Name

Fibre Channel Port name or
Fibre Channel Port name : storage processor name if the target is Remedyforce.

ShortDescription

Fibre Channel Port name

Description

Fibre Channel Port name : WWPN

LinkTechnology

4. (Fibre Channel)

ManufacturerName

Storage processor vendor

Model

Storage processor model

PermanentAddress

Fibre Channel Port WWPN

PortType

6. (Fibre Channel)

Company

Host Company

Category

"Hardware"

Type

"Card"

Item

"Fibre Channel HBA card"

BMC_NetworkPort relationship

Relationship

Name

Source

Destination

BMC_HostedSystemComponents
SYSTEMHARDWARE

BMC_ComputerSystem 
(Storage System)

BMC_NetworkPort
BMC_Component
SUBHWCOMPONENT

BMC_HardwarePackage
(Storage Processor)

BMC_NetworkPort

BMC_LANEndpoint

Attribute

Details

Name

MAC Address

NameFormat

"MAC"

ShortDescription

MAC Address (with colons)

Description

"MAC address on hostname"

Address

MAC address (no separating colons)

MACAddress

MAC address (no separating colons)

ProtocolType

14. (Ethernet)

Company

Network Interface Company

Category

"Network"

Type

"Address"

Item

"MAC Address"

BMC_LANEndpoint relationships

Relationship

Name

Source

Destination

BMC_HostedAccessPoint
HOSTEDACCESSPOINT

BMC_ComputerSystem 
(Storage System)

BMC_LANEndpoint
BMC_Dependency
ENDPOINTPORT
BMC_NetworkPort
BMC_LANEndpoint

BMC_IPEndpoint

Attribute

Details

Name

IP address ip_addr

NameFormat

"IP"

ShortDescription

IP address ip_addr

Description

IP address name

AddressType

IPv4 (1) or IPv6 (2)

Address

IP address ip_addr

DNSHostName

IP address fqdns (first item in list)

ManagementAddress

Yes (1) if the IP address was used to scan the host; No (0) if not. (Not in CMDB 7.5.)

ProtocolType

IPv4 (2) or IPv6 (3)

PrefixLength

IPv6 prefix length in bits

SubnetMask

IPv4 subnet mask

Company

Network Interface Company

Category

"Network"

Type

"Address"

Item

"IP Address"

BMC_IPEndpoint relationships

Relationship

Name

Source

Destination

BMC_HostedAccessPoint
HOSTEDACCESSPOINT

BMC_ComputerSystem 
(Storage System)

BMC_IPEndpoint
BMC_HostedAccessPoint
HOSTEDACCESSPOINT

BMC_ComputerSystem 
(Storage System Group)

BMC_IPEndpoint
BMC_Dependency
ENDPOINTPORT
BMC_NetworkPort
BMC_IPEndpoint
BMC_Dependency
BINDSTO
BMC_LANEndpoint
BMC_IPEndpoint

BMC_IPConnectivitySubnet

The Subnet node is mapped to BMC_IPConnectivitySubnet.

Attribute

Details

Name

Subnet ip_address_range or

Subnet ip_address_range : Subnet scope

ShortDescription

Subnet ip_address_range

Description

Subnet ip_address_range

SubnetNumber

Subnet ip_address_range

AddressType

IPv4 (1) or IPv6 (2)

PrefixLength

IPv6 prefix length in bits

SubnetMask

IPv4 subnet mask

Company

Cluster Company

Category

"Network"

Type

"Subnet"

Item

"TCP/IP"

BMC_IPConnectivitySubnet relationships

Relationship

Name

Source

Destination

BMC_InIPSubnet
INIPSUBNET
BMC_IPConnectivitySubnet
BMC_IPEndpoint

BMC_Cluster

The StorageSystemGroup node is mapped to the BMC_Cluster CI.

Attribute

Details

TokenId

TokenId is of the form "ADDM:StorageSystemGroup key".

See TokenId rules.

Name

StorageSystemGroup name.

ShortDescription

StorageSystemGroup name.

Description

StorageSystemGroup name.

ManufacturerName

StorageSystem vendor.

Model

StorageSystemGroup type.

SerialNumber

StorageSystemGroup serial.

Company

StorageSystemGroup Company.

Category

"Hardware"

Type

"Storage"

Item

"Storage cluster"

Where clustered, the StorageSystem node is also mapped to the BMC_Cluster CI.

Attribute

Details

TokenId

TokenId is of the form "ADDM:Device key".

See TokenId rules.

Name

StorageSystem name.

ShortDescription

StorageSystem name.

Description

StorageSystem name.

ManufacturerName

StorageSystem vendor.

Model

StorageSystem type.

Company

StorageSystem Company.

Category

"Hardware"

Type

"Storage"

Item

"Storage cluster"

When the pool StorageSystemGroup node is clustered, it is also mapped to the BMC_Cluster CI.

Attribute

Details

TokenId

TokenId is of the form "ADDM:Cluster key".

See TokenId rules.

Name

Cluster name.

ShortDescription

Cluster name.

Description

Cluster name.

ManufacturerName

Cluster vendor.

Model

Cluster type.

SerialNumber

Cluster serial number.

ComponentAliases

Cluster cdm_component_aliases

Company

StorageSystem Company.

Category

"Hardware"

Type

"Storage"

Item

"Storage cluster"

BMC_Cluster relationships

Relationship

Name

Source

Destination

BMC_Component
CLUSTEREDSYSTEM

BMC_ClusterImpacted

BMC_ComputerSystem
BMC_Component
HOSTEDRESOURCEPOOL
BMC_Cluster

BMC_ResourcePool
Impacted

TokenId rules

TokenId is an attribute that, in some circumstances, aids the reconciliation of CIs populated by multiple data sources. BMC Helix Discovery sets TokenId depending on the Node kind.

For most Nodes, TokenId is one of the forms:

key

or

ADDM:%key%

or

ADDM:%hashed_key%

For databases, TokenId is a database host found as a result of all possible combinations of where the database might be running:

%hosting_ci.TokenId%:%database_node.type%:%si_instance%:%database_node.instance%

and

%hosting_ci.Name%:%database_node.type%:%si_instance%:%database_node.instance%

For the Fibre Channel Node, TokenId is of the form:

WWN:%wwpn% 

For physical hosts, TokenId is of the form:

%host.hostname%:%host.dns_domain%

If the domain name is unavailable, then

%host.hostname%

For virtual hosts that are running in the cloud, TokenId contains instance_id.

  • For Alibaba, TokenId is of the form:
%alibaba_instance_id%
  • For Azure, TokenId is of the form:
%azure_vm_id%
  • For AWS, TokenId is of the form:
%aws_instance_id%
  • For GCP, TokenId is of the form:
%gce_instance_id%
  • For IBM, TokenId is of the form:
%instance_id%
  • For OCI, TokenId is of the form:
%ocid%

For virtual hosts that are running in the hypervisor, TokenId contains UUID.

  • For AHV, TokenId is of the form:
AHV-UUID:%uuid%
  • For Hyper-V, the UUID is only available on the physical machine, so TokenId is only set for virtual machines that have been successfully linked to their hosting physical machines:
HYPERV-ID:%vm_uuid%
  • For KVM (including RedHat Enterprise Virtualization), TokenId is of the form:
KVM-ID:%uuid%
  • For VMware, TokenId is of the form where each letter represents a hexadecimal digit:
VI-UUID:%uuid%
  • For Xen (including Oracle VM), TokenId is of the form: 
XEN-ID:%uuid%

The following table shows how TokenId looks like for different Node Kinds:

Node Kind

CI

TokenId

AdminCollection

BMC_AdminDomain

key

Cluster (cloud)

BMC_Cluster

key

LoadBalancerService

BMC_LogicalSystemComponent

ADDM:%key%

LoadBalancerPool

BMC_ResourcePool

ADDM:%key%

CloudManagementGroup

BMC_AdminDomain

cloud_id

CloudProvider

BMC_CloudInstance

key

CloudRegion

BMC_CloudInstance

key

CloudService

BMC_CloudInstance

key

Cluster

BMC_Cluster

ADDM:%hashed_key%

Database (cloud)

BMC_DataBase

ADDM:%key%

Database


BMC_DataBase


%hosting_ci.TokenId%:%database_node.type%:%si_instance%:%database_node.instance%
%hosting_ci.Name%:%database_node.type%:%si_instance%:%database_node.instance%

HardwareComponent

BMC_HardwareSystemComponent

ADDM:%hashed_key%

HardwareContainer

BMC_ComputerSystem

ADDM:%hashed_key%

HostContainer

BMC_ComputerSystem

ADDM:%hashed_key%

Host








BMC_ComputerSystem








%host.hostname%:%host.dns_domain%
%host.hostname%
ALIBABA-ID:%alibaba_instance_id%
AWS-ID:%aws_instance_id%
GCP-ID:%gce_instance_id%
IBM-ID:%instance_id%
OCI-ID:%ocid%
AZURE-ID:%azure_vm_id%
HYPERV-ID:%vm_uuid%
XEN-ID:%uuid%
KVM-UUID:%uuid%
AHV-UUID:%uuid%
VI-UUID:%uuid%

LoadBalancerGroup

BMC_Cluster

ADDM:%key%

MFPart

BMC_ComputerSystem

key

Namespace

BMC_AdminDomain

key

Deployment

BMC_ConcreteCollection

key

NetworkService

BMC_LogicalSystemComponent

ADDM:%key%

FibreChannelPort

BMC_NetworkPort

WWN:%wwpn%

SoftwareCluster

BMC_Cluster

ADDM:%hashed_key%

SoftwareComponent

BMC_ApplicationService

ADDM:%hashed_key%

SoftwareInstance

BMC_ApplicationSystem

ADDM:%hashed_key%

SoftwareInstance

BMC_SoftwareServer

ADDM:%hashed_key%

VirtualMachine

BMC_VirtualSystemEnabler

ADDM:%hashed_key%

StorageDevice

BMC_Cluster

ADDM:%key%

StoragePool

BMC_ResourcePool

ADDM:%key%

StorageSystemGroup

BMC_Cluster

ADDM:%key%

StorageProcessor

BMC_HardwarePackage

ADDM:%key%

HardwareContainer

BMC_HardwareSystemComponent

ADDM:%hashed_key%

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*