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 86031 is 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

Parameter

Description

Example

Required

username

Contains the ADDM user name with permissions to push the events into ADDM

user

Yes

password

Contains the logon password for the ADDM user

password

Yes

event

Contains the name of the event

VmMigratedEvent

Yes

vmid(uuid)

Contains the unique identifier of the VM whose status has changed

50046553-4f2e-a3b6-22f0-9c60eb280f44

Yes

vm-label

Contains the name of the VM that was moved

ADDM-VM

No

source-host-label

Contains the name of the ESX host from where the VM was moved

esx.1.bmc.com

No

target-host-label

Contains the name of the new ESX host to where the VM was moved

esx2.bmc.com

No

Was this page helpful? Yes No Submitting... Thank you

Comments