This documentation supports the 20.02 version of BMC CMDB.

To view an earlier version, select the version from the Product version menu.

Virtual system models

Virtual systems represent one or more virtual machines that are hosted by a physical computer. A virtual system has an operating system, network addresses, and software and shares the same relationship with its sub components and applications that a physical system does. The only difference is that these subcomponents, although captured as regular CIs, are all virtual. Additionally, virtual systems can have BMC_Genealogy relationships that define relationships between a parent virtual system and its child virtual systems. For example, If you have a virtual system named win2k-vm1 and a clone of that system named win2k-vm2, the win2k-vm1 system is the parent and the win2k-vm2 system is the child. 


Related Topics

When modeling virtual systems in your environment, you must represent the virtual computer system by using the BMC_ComputerSystem class. You must represent the virtualization software, such as hypervisor or virtualization software by using the BMC_VirtualSystemEnabler class.


Example of modeling multiple virtual systems without resource pools and settings

The following figure illustrates multiple virtual systems or VMs, the physical computer system that hosts them, and the virtualization operating system. The virtual operating system is hosted on the physical system and runs the VMs. The diagram is simplified and does not contain resource pools. 
 


Logical identity of BMC_System and BMC_ComputerSystem for virtual systems

Virtual systems are modeled as instances of BMC_ComputerSystem, a subclass of BMC_System. You must follow the same naming rules that you would follow for an instance of BMC_ComputerSystem class. For more information about this class, see Logical identity of BMC_ComputerSystem.

The key attributes for defining virtual systems are VirtualSystemType (for the BMC_ComputerSystem class) and isVirtual for the BMC_System and BMC_SystemComponent classes and their subclasses. Both attributes are described in the following table:

Attribute

Usage

VirtualSystemType

Identifies the type of virtual machine.

Values are Other (0), Unknown (1), PR/SM (2), z/VM (3), VMWare (4), Xen (10), Hyper-V (15), Oracle  Solaris Container (20), VPar (25), NPar (30) and LPar (35).

isVirtual

Specifies whether the instance is virtual or physical.

Values are NULL, No (0), or Yes (1).

If you know that a CI is a virtual machine, use Yes. If you know that the CI is a physical machine, use No. If you are unsure, use NULL.

Note

In version 19.08, a new isVirtual attribute has been added to the BMC_BaseElement class. This move expands the virtualization scope beyond computer systems, enabling you to represent any device (CI) as a logical entity rather than as a physical entity. The existing attribute on all the three classes, BMC_SystemBMC_SystemComponent, and BMC_Collection has been renamed to isVirtual_old. The data that is stored in isVirtual_old attribute is maintained as it is.

For more information, see Summary of changes to the Common Data Model.

Logical identity of BMC_VirtualSystemEnabler

The BMC_VirtualSystemEnabler class stores information about software that enables a collection of virtual computer systems to run on a single physical computer system (for example, VMware). This class is used to capture the virtualization OS, such as operating systems that run virtual machines (including VMware images, Solaris zones, IBM ® AIX ® logical partitions, HP-UX virtual partitions, and so forth).

The BMC_VirtualSystemEnabler class is associated to the parent computer system instance by the BMC_HostedSystemComponents relationship.

As a subclass of BMC_ComputerSystem, any instance (representing a new business CI) of the BMC_VirtualSystemEnabler class is identified, at minimum, by the Name and SystemName attributes.


Key attributes for BMC_VirtualSystemEnabler

The key attribute for BMC_VirtualSystemEnabler is EnablerType, and is described in the following table:

Attribute

Usage

EnablerType

Specifies the virtualization software or OS. The possible values are Other (0, the default), Unknown (1), PR/SM (2), z/VM (3), VMWare Server (4), Solaris Resource Manager (5), LPar (6), VPar (7), HP nPartitions (20), Integrity VM (25), Microsoft Hyper-V (30), VMWare ESX Server (35), VMWare Workstation (40), Xen Hypervisor (45), and LDOM Hypervisor (50).

For a complete list of attributes for the BMC_VirtualSystemEnabler class, see the BMC CMDB CDM Help.


Key attributes for BMC_VirtualSystemSettingData

The BMC_VirtualSystemSettingData class (derived from BMC_Settings ) provides additional granularity about a virtual system's settings through a set of virtualization-specific properties. The key attributes for defining the virtual aspects by using the BMC_VirtualSystemSettingData class are described in the following table:

Attribute

Usage

VirtualSystemState

Specifies the state of the virtual machine. Values are Other (0), Unknown (1), Active (10), InActive (15), Suspended (20), and Disabled (25).

VirtualSystemType

Specifies a type of virtual system. Values are Other (0),Unknown (1), LPAR (2), VM/VM Guest (3), VMware (4), Xen (20), LDOM (25), Solaris Container (30), HP nPartitions (35), VPar (40), and Microsoft Hyper-V (45).

ActualProvisionDate

The date and time that a specific VM was provisioned. This attribute is important for enabling successful reporting on BMC Dashboards.

ProposedDecommissionDate

The date and time that the VM is removed from the environment. One of the biggest problems causing virtual system sprawl is that organizations do not decommission VMs and track the information. This attribute helps to drive workflow actions such as:

  • Notifying users that their VM is about to be decommissioned and enabling them to extend the time before the event occurs.
  • Automatically creating change requests to begin the decommissioning process.
  • Automatically starting a job in BMC BladeLogic, BMC Orchestrator, and other consuming applications to decommission the virtual machine.

ActualDecommissionDate

The date of the actual decommission. There can be an extension to that date to enable you to report or track a VM. You can also compare differences between the decommission date and actual decommission date, or block future updates to the extension date.

Example of modeling a virtual system environment with settings and containers

The following figure displays an organization that has a virtual system environment, where a Solaris server is divided into two domains (LDOM1 and LDOM2), which are further divided into containers (Container1 and Container2).

For the virtualization environment, use BMC_ComputerSystem, where the isVirtual attribute is set to Yes. The parent system, which is either virtual or physical must be related to the virtual system with a BMC_Dependency relationship where the Name attribute has a value of HostedVirtualSystem. To model the virtualization technology, BMC_VirtualSystemEnabler is related to the host system with the appropriate EnablerType attribute set to the correct type of software (for example, LDOM hypervisor) and relationships are set to BMC_ComputerSystem (the physical computer).

For containers, create relationships to BMC_VirtualSystemEnabler (Solaris Resource Manager) to the domain (or physical computer, depending on the configuration), and to the operating system.

Logical domain virtual systems with settings and containers


Logical identity of BMC_ResourcePool (for virtual systems)

The BMC_ResourcePool class serves as a logical entity (with associated controls) provided by the host system to allocate and assign resources. A resource pool may be used to allocate resources of a specific type. Hierarchies of resource pools may be created to provide administrative control over allocations. In cases where resources are subdivided, multiple resource pools may exist.


Key attributes for defining BMC_ResourcePool

Key attributes for defining resource pools using the BMC_ResourcePool class are described in the following table:

Attribute

Usage

Primordial

Specifies how the resource pool is used in the activity of resource management. If set to true, this attribute indicates that the resource pool is a base from which resources are drawn and returned in the activity of resource management. It also indicates that this resource pool shall not be created or deleted by consumers of this model. However, other actions (whether they are modeled or not), may affect the characteristics or size of primordial resource pool. If set to false (the default), this attribute indicates that the resource pool serves as a concrete resource pool, meaning that is subject to resource allocation services functions. This distinction is important, because higher-level resource pools may be assembled using the Component or ElementAllocatedFromPool associations. Although the higher-level abstractions can be created and deleted, the most basic, hardware-based resource pools (such as primordial pools) cannot. Instead, they are physically realized as part of the system, or are actually managed by some other system and imported as if they were physically realized.

ResourceType

Specifies the type of resource that the resource pool may allocate.

Values are Other (0), Computer System (2), Processor (3), Memory (4), IDE Controller (5), Parallel SCSI HBA (6), FC HBA (7), iSCSI HBA (8), IB HCA (9), Ethernet Adapter (10), Other Network Adapter (11), I/O Slot (12), I/O Device (13), Floppy Drive (14), CD Drive (15), DVD drive (16), Disk Drive (17), Tape Drive (18), Storage Extent (19), Other storage device (20), Serial port (21), Parallel port (22), USB Controller (23), Graphics controller (24), IEEE 1394 Controller (25), Partitionable Unit (26), Base Partitionable Unit (27), Power (28), Cooling Capacity (29), Ethernet Switch Port (30), Logical Disk (31), Storage Volume (32), Ethernet Connection (33)


In systems that support over-commitment, pools represent the reservable capacity, not an upper bound or limit on the maximum amount that can be allocated. Admission control during power-on may detect and prevent systems from powering due to resource exhaustion. For example, over-commitment on a resource pool with ResourceType set to Memory would require that sufficient space be available in a backing store that might be managed through a storage resource pool.


Logical identity of BMC_ResourceAllocationSettingData (for virtual systems)

The BMC_ResourceAllocationSettingData class (derived from BMC_Settings ) represents settings that specifically relate to an allocated resource.

Use BMC_VirtualSystemSettingData and BMC_ResourceAllocationSettingData to represent virtual system settings, and BMC_ResourcePool to model resource pools.

The key attribute for defining settings using the BMC_ResourceAllocationSettingData class is ResourceType, described in the following table:

Attribute

Usage

ResourceType

Specifies the type of resource that this allocation setting represents. Values are Other (0), Computer System (2), Processor (3), Memory (4), IDE Controller (5), Parallel SCSI HBA (6), FC HBA (7), iSCSI HBA (8), IB HCA (9), Ethernet Adapter (10), Other Network Adapter (11), I/O Slot (12), I/O Device (13), Floppy Drive (14), CD Drive (15), DVD drive (16), Disk Drive (17), Tape Drive (18), Storage Extent (19), Other storage device (20), Serial port (21), Parallel port (22), USB Controller (23), Graphics controller (24), IEEE 1394 Controller (25), Partitionable Unit (26), Base Partitionable Unit (27), Power (28), Cooling Capacity (29), Ethernet Switch Port (30).


Example of modeling a virtual system with one resource pool and resource allocation

Using the following figure as an example, a physical box is related to BMC_ResourcePool by BMC_Component where the Name attribute is set to HostedResourcePool. Use the relationship class BMC_MemberOfCollection, where the Name attribute is set to{{isMemberofPool}} to allocate resources and resource pools. You can use the relationship class BMC_Dependency, where the Name attribute is set to ElementAllocatedFromPool to allocate resources and resource pools. You can also use the relationship class BMC_Dependency, where the Name attribute is set to ResourceAllocationFromPool to allocate resources and resource pools.

Model of a virtual system with one resource pool and resource allocation


Deprecated classes for virtual systems

The following classes were deprecated in BMC Atrium CMDB 7.5.00, and are no longer used for modeling virtualized environments:

  • BMC_VirtualSystem (including all subclasses)
  • BMC_VMWare
  • BMC_VMWareVirtualSystem
  • BMC_UnixVirtualSystem
  • BMC_MFVirtualSystem
  • BMC_MFVirtualSystemEnabler
  • BMC_LPAR


Relationships for virtual system

The following table describes the relationships for virtual systems:

Relationship

Relationship class

Value of Name attribute

Managed elements and setting data

BMC_SettingsOf

ELEMENTSETTINGDATA

Allocated resource and resource pool

BMC_MemberOfCollection

ISMEMBEROFPOOL

Resource allocated from a pool

BMC_Dependency

ELEMENTALLOCATEDFROMPOOL




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

Comments

  1. Thomas Hammer

    Please check the Note about the isVirtual flag.

    Note

    In BMC Atrium CMDB 7.6.00, the isVirtual attribute ...

    It has been changed again in the meantime AFAIK

    Jun 26, 2020 04:18
    1. Kanchana Iyer

      Hello Thomas,

      Thanks for your comment. The note has been updated now.

      Regards,

      Kanchana

      Aug 05, 2020 09:34