The causes that flow from an element to an instance through a relationship are determined as follows:

  1. Find the element for a given notification

  2. Use the specified relationship to find related instances

  3. See if there are corresponding notifications

    As an example, the PowerSupply::network:86.2.2.2:PowerSupply-1::Down NCI is specified as “occurring on an instance related to the notified element” in the VMware Smart Assurance NOTIF Editor and the relationship is ComposedOf. Assume the .PowerSupply.Down Causes .Card.Down. If a .PowerSupply.Down notification is created, VMware Smart Assurance NOTIF will find its element (probably a Router) then follow the ComposedOf relationship. This would find all the Router's Cards and if any of those cards had Card.Down notifications, then those notifications would be related to the .PowerSupply.Down notification.

    The advantage of this specification is that several objects within the element may be able to transfer causality without being directly related.

    Looking at this causality in the inverse direction, the Card.Down NCI would show that relationship is followed in the instance to element direction and the relationship would be PartOf. When a Card.Down notification is created, it would follow its PartOf relationship to find an element, then look for all the notifications associated with that element, looking for a .PowerSupply.Down.

    Note:

    The “occurring on an instance related to the notified element” specification can be very processor-intensive for environments with large numbers of active notifications. Therefore, it is recommended that use of this specification be kept to a minimum.