Discovery and CMDB update workflow

One of the advantages virtualization offers is rapid, automated VM management in the event that a physical host cannot provide resources to a virtual server. In this scenario, you can migrate a VM to another host that has greater available resource capacity, creating a VmMigratedEvent. Because this change is unplanned but pre-approved by the VMware policy, a change request or change approval is not required. In another scenario, a VM migrates from a failing ESX host to healthy ESX host, creating an automated DrsVMMigratedEvent. In both cases, the monitor adapter receives a notification that the VMotion event occurred.

When the monitor adapter receives the VMotion event notification, the Process Incoming Event workflow is invoked and initiates the run book activity. The workflow, shown in the following figure, executes on one of two different paths, depending on the type of event generated. The 86031is then called when the incoming event is detected as a manual VmMigratedEvent.

Process Incoming Event workflow

In the case of a manual VM migration, the workflow uses the event information picked up by the adapter and triggers BMC Discovery to run a rescan, which updates the CMDB with the new virtual machine location.

Discovery and CMDB update workflow

The VmMigratedEvent, a sample of which is shown below, initiates the Extract Configuration Data workflow which extracts the module configuration data. With the VMware monitor adapter version 20.11.02, the universally unique identifier (UUID) of the migrated VM is part of the VmMigratedEvent. The workflow extracts the UUID from the event.

Note

The VMware monitor adapter version 20.11.01 initiates the Extract Configuration Data workflow. This workflow extracts the module configuration data. It then calls the Get VM Configuration Details operations action workflow on the VMWare adapter to retrieve the UUID of the migrated VM.

In the case of the VmMigratedEvent, the Post workflow passes the required parameters, shown in the following table, by calling the ADDM application using the HTTP POST method. The workflow then creates a latent change ticket with the required details updated in the ticket workinfo.

If the VM is already discovered, the BMC Atrium Discovery and Dependency Mapping application synchronizes the CMDB.

Note

In the case of datastore migration, the source and destination hosts remain the same. ADDM is not triggered for a CMDB update, and a change record is not created.

VmMigratedEvent input event sample

<vmware-monitor-event>
<returnval>
   <version>10</version>
   <changeSet>
     <name>latestPage[112984]</name>
     <op>remove</op>
   </changeSet>
   <changeSet>
     <name>latestPage[112992]</name>
     <op>add</op>
     <VmMigratedEvent>
       <key>112992</key>
       <chainId>112984</chainId>
       <createdTime>2011-05-20T03:50:57.248125Z</createdTime>
       <userName>Administrator</userName>
       <datacenter>
         <name>Aspen DataCenter-1</name>
         <Datacenter>datacenter-21</Datacenter>
       </datacenter>
       <computeResource>
         <name>Aspen Cluster-1</name>
         <ClusterComputeResource>domain-c26</ClusterComputeResource>
       </computeResource>
       <host>
         <name>aus-esx-asp01.bmc.com</name>
         <HostSystem>host-42</HostSystem>
       </host>
       <vm>
         <name>DiscSyncVM</name>
         <VirtualMachine>vm-1937</VirtualMachine>
         <uuid>422f5893-3af4-d812-7b84-d91096c98652</uuid>
       </vm>
       <fullFormattedMessage>Migration of virtual machine DiscSyncVM from aus-r210-esx-05.bmc.com to aus-esx-asp01.bmc.com completed</fullFormattedMessage>
       <changeTag></changeTag>
       <template>false</template>
       <sourceHost>
         <name>aus-r210-esx-05.bmc.com</name>
         <HostSystem>host-139</HostSystem>
       </sourceHost>
       <virtualCenter>aus-asp-vc01.bmc.com</virtualCenter>
     </VmMigratedEvent>
   </changeSet>
</returnval>
</vmware-monitor-event>

A DrsVmMigratedEvent, a sample of which is shown in the following figure, occurs during VMware server maintenance activities. It is created when there is an automatic migration of a VM. In this case, the workflow creates a latent change in BMC Remedy ITSM.

DrsVmMigratedEvent input event sample

<vmware-monitor-event>
<returnval>
   <version>5</version>
   <changeSet>
     <name>latestPage[112957]</name>
     <op>remove</op>
   </changeSet>
   <changeSet>
     <name>latestPage[112967]</name>
     <op>add</op>
     <DrsVmMigratedEvent>
       <key>112967</key>
       <chainId>112957</chainId>
       <createdTime>2011-05-20T03:45:56.8575Z</createdTime>
       <userName></userName>
       <datacenter>
         <name>Aspen DataCenter-1</name>
         <Datacenter>datacenter-21</Datacenter>
       </datacenter>
       <computeResource>
         <name>Aspen Cluster-1</name>
         <ClusterComputeResource>domain-c26</ClusterComputeResource>
       </computeResource>
       <host>
         <name>aus-r210-esx-05.bmc.com</name>
         <HostSystem>host-139</HostSystem>
       </host>
       <vm>
         <name>TestVM</name>
         <VirtualMachine>vm-1299</VirtualMachine>
         <uuid>564d09a7-9fbd-55bc-ea37-80a50d094767</uuid>
       </vm>
       <fullFormattedMessage>DRS migrated TestVM from aus-esx-asp01.bmc.com to aus-r210-esx-05.bmc.com in cluster Aspen Cluster-1 in Aspen DataCenter-1</fullFormattedMessage>
       <changeTag></changeTag>
       <template>false</template>
       <sourceHost>
         <name>aus-esx-asp01.bmc.com</name>
         <HostSystem>host-42</HostSystem>
       </sourceHost>
       <virtualCenter>aus-asp-vc01.bmc.com</virtualCenter>
     </DrsVmMigratedEvent>
   </changeSet>
</returnval>
</vmware-monitor-event>

Event parameters passed to BMC Atrium Discovery and Dependency Mapping

Discovery and CMDB update workflow

On this page