During a recent client meeting the request was made that we integrate VMware servers which we monitor with Operations Manager 2012 into Service Manager 2012 as Configuration Items (CI’s). We are using Veeam’s VMware monitoring management pack to provide monitoring for VMware in Operations Manager 2012.
From a high level these were the steps required (identified by Pete Zerger in http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/87781/Default.aspx):
(1) find out what the correct class name is for the VMware devices.
(2) import the management pack that contains that class definition into SM.
(3) use the powershell cmdlet to add the class to the whitelist. [This step was NOT required in Service Manager 2012]
(4) edit the properties of the CI connector and put a checkmark in the box before your MP name so it will sync it and then hit "Sync Now".
(5) Create a new view under Configuration Items that shows any CI object of that class type (so you can see them).
More detailed steps:
(1) Finding out what the correct class name is for VMware devices in OpsMgr 2012
For this one, Oskar Landman to the rescue at: http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/81851/Default.aspx
Oskar’s article was written about Service Manager 2010 and Operations Manager 2007 R2 but the ideas almost all still apply.
Finding the class name for VMware devices: using the Discovered Inventory view in the Monitoring pane showed the results below from my home lab. This shows that “nworks VMware” is what I care about for these network devices in Operations Manager.
On OpsMgr 2012 using PowerShell:
Get-SCOMClass | Where-object {$_.Displayname –match “nworks VMware”}
The result indicates that I need to add a variety of classes which are included in the nworks.VMware.VEM management pack.
(2) import the management pack that contains that class definition into Service Maqnager.
I found that I needed the following management packs to get my lab environment to synchronize these network devices as CI’s:
- nworks.VMware.VEM.mp
Which failed to import originally due to a dependency on one management pack:
- Microsoft.SystemCenter.DataWarehouse.Report.Library
After adding the Microsoft Generic Report Library the Veeam MP imported correctly: 
The VMware dependencies in Service Manager are shown below: [Please note that this process was done after integrating Network Devices so additional MP’s from the list below will also most likely need to be added to allow the import of the Veeam management pack. Discussion on these steps are available at https://www.catapultsystems.com/cfuller/archive/2012/07/13/how-do-i-integrate-operations-manager-2012-network-devices-into-service-manager-2012-as-configuration-items-[scsm-scom-sysctr].aspx.]
The VMware classes appeared without having to do the PowerShell scripts discussed in the Network Devices blog post.
(To find what objects are used, match the view of the data provided by Veeam in OpsMgr and look at the properties of the view used in Operations Manager as shown below)
(3) use the powershell cmdlet to add the class to the whitelist. [This step was not required]
(4) edit the properties of the CI connector and put a checkmark in the box before your MP name so it will sync it and then hit "Sync Now".
In Service Manager, changed the connector for Operations Manager CI’s:
To include the new management pack: (checked the box shown below for “nworks.VMware.VEM”)
(5) Create a new view under Configuration Items that shows any CI object of that class type (so you can see them).
In Service Manager in the Configuration Items view, I created a folder called “VMware”.
After this I created a view for each of the major pieces of the VMware Infrastructure based upon the class list shown below:
Within this I created several views – the first containing all CI’s to see what existed in the Service Manager CI list and additional views to show specific CI’s for VMware. The VMware – All CI’s view looks like the graphic shown below. The VMware devices view was defined based on the class “nworks VMware” in Service Manager:
To display specific data, individual views were created for VMware ESX Clusters as shown below: (fields available include Asset Status, Connector Identifier, Datacenter Name, Display Name, effectiveCPUGHz, effectiveMemoryGB, Full Name, ID, Last modified, Name, Notes, numCpuCores, numCpuThreads, numEffectiveHosts, numHosts, Object Status, Path, Time Added, totalCPUGhz, totalMemoryGB, vCenter Name, vmActive, vmShutdown, vmSuspended):
Additional views were created for VMware ESX Hosts as shown below: (fields available include Asset Status, Cluster Name, Connection Identifier, cpuCores, CpuGhz, cpuPkgs, cpuThreads, Display Name, Full Name, id, ipAddress, Last Modified, Name, Node Name, Notes, nworksCollector, Object Status, Path, powerState, Segment, systemModel, TaskPath, TimeAdded, Total Memory GB, vcenter Name, VMware ID, VMware version).
And a view was created for VMware Virtual Machines as shown below: (fields available include Allocated Max Memory GB, Asset Status, Cluster Name, Connector Identifier, CPU Count, CPU Reservation, Datacenter Name, Display Name, DNS Name, Enable VM Child Objects, ESX Host Name, Full Name, Guest OS, ID, Last Modified, Memory Reservation, Name, Node Name, Notes, nworksCollector, Object Status, Path, Resource Pool Name, Segment, TaskPath, Time Added, Unique ID, vApp Name, vCenter Name, VMTools Version).
There are also a significant number of fields gathered for the various VMware objects including the example below which shows the details available for an ESX host.
As expected these VMware related devices also integrated correctly into Service Manager such as in the example below where an ESX host is being added to an emergency change request.
This also integrates the pieces of VMware servers such as HBA’s which can be added to a change control by identifying the HBA from the list of configuration items as shown below:
I owe huge thanks to both Chris Ross for his insights on this topic and to Pete Zerger and Oskar Landman for blazing the trail required to build the foundation to making this feasible for an OpsMgr geek such as myself! And finally to Alec King and Brian Pavnick – Alec for bringing this idea to light, and Brian for his help getting me what I needed to make this happen!
Additional recommended reading on this topic:
My original article on adding Network Devices into Service manager: https://www.catapultsystems.com/cfuller/archive/2012/07/13/how-do-i-integrate-operations-manager-2012-network-devices-into-service-manager-2012-as-configuration-items-[scsm-scom-sysctr].aspx
Pete Zerger’s article on including non-Windows devices from Operations Manager into the Service Manager CMDB: http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/87781/Default.aspx)
Oskar Landman’s article on configuring the SCOM CI connector in System Center Service Manager 2010: http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/81851/Default.aspx