Virtual lifecycle management

Virtual lifecycle management focuses on the control of virtual machine (VM) discovery, creation, management, and retirement.

Products involved

Following are the primary products involved in this use case:

• BMC Atrium
  • BMC Atrium Discovery and Dependency Mapping
  • BMC Atrium Core (BMC Atrium CMDB)
• Service Assurance
  • BMC ProactiveNet Performance Management
• Service Automation
  • BMC Atrium Orchestrator
  • BMC BladeLogic Decision Support for Server Automation
  • BMC BladeLogic Server Automation
  • BMC BladeLogic Network Automation
• Service Support
  • BMC Remedy IT Service Management (ITSM)
    • BMC Asset Management
    • BMC Change Management
  • BMC Service Request Management

Prerequisites

• BMC Atrium Discovery runs against all VMs that are to be tracked in the CMDB. Discovered VMs are reconciled into the production dataset.
• Other BMC products extract information from the CMDB to perform service-aware functions. Such products include:
  • BMC BladeLogic Server Automation
  • BMC BladeLogic Network Automation
  • BMC ProactiveNet Performance Management
• BMC BladeLogic Server Automation runs Component Discovery on enrolled VMs.
• Information from BMC BladeLogic Server Automation is extracted to BMC BladeLogic Decision Support for Server Automation and pushed into the BMC BladeLogic Server Automation import dataset in the CMDB and reconciled with the production dataset.

Technical use case

The virtual lifecycle management use case consists of discovery, provisioning, and decommissioning.

Discovery of a VM infrastructure change

1. BMC Atrium Orchestrator receives an SNMP trap on any of a number of events, including VMotion or other VM state changes.
2. BMC Atrium Orchestrator creates a change request in BMC Change Management to record the change, using a predefined change request template. If a change request is already open for the event, the change request is updated to show that the event has occurred. Otherwise, a new request is created.
3. BMC Atrium Orchestrator calls BMC Atrium Discovery, which might have all the information it needs to update the datastore and CMDB, or might perform a rescan.
4. BMC Atrium Discovery pushes the updated information to the CMDB, where it is reconciled into the production dataset.

VM provisioning

1. A user of the BMC Service Request Management Request Console selects a service request for provisioning a system.
2. BMC Service Request Management references the BMC Atrium Service Catalog.
3. BMC Service Request Management invokes a BMC Atrium Orchestrator workflow, passing in all required information. The specific workflow to invoke is specified in the Service Request Definition.
4. BMC Atrium Orchestrator creates a change request in BMC Change Management.
5. BMC Change Management passes its approval of the change back to BMC Atrium Orchestrator.
6. BMC Atrium Orchestrator manages interactions with BMC BladeLogic Server Automation, BMC BladeLogic Network Automation, and third-party storage automation providers as necessary.
7. When the change is complete, BMC Atrium Orchestrator updates the change request in BMC Change Management to indicate completion and pushes basic information about the new server into the CMDB.
8. BMC BladeLogic Server Automation provides more detailed information about the new server to the CMDB.
9. BMC Asset Management can now reference the CMDB for information about the new server.

VM process-driven decommissioning

The workflow for lifecycle control and the decommissioning of a VM is similar to the VM provisioning workflow.

1. BMC Asset Management raises an escalation to notify the user of an upcoming expiration, usually via email.
2. The user uses the BMC Service Request Management Request Console to request an extension. The Request Console references the BMC Atrium Service Catalog.
3. The service request is passed to the BMC Service Request Management Fulfillment Engine when the user submits the request.
4. The BMC Service Request Management Fulfillment Engine invokes a BMC Atrium Orchestrator workflow, passing in all required information.
5. BMC Atrium Orchestrator creates a change request in BMC Change Management using a predefined change template.
6. When the change request is approved, BMC Change Management passes the approval back to BMC Atrium Orchestrator.
7. BMC Atrium Orchestrator manages interactions with BMC BladeLogic Server Automation, BMC BladeLogic Network Automation, and third-party storage automation providers as necessary.
8. When all steps have been completed, BMC Atrium Orchestrator updates the change request in BMC Change Management to indicate completion.
9. BMC Atrium Orchestrator pushes the updated expiration date into the BMC Atrium CMDB.
10. If the server owner does not extend the expiration, the server is automatically decommissioned.