VMWare Vcenter Discovery or PowerCLI

smouazzen
Tera Contributor

Hi All, 

I am very new to ServicenNow and we are trying to compare VMWare Discovery to a PowerCLI script to fetch all the CI data from our Vcenter implementation. Basically we need to understand the licenses impact by using Discover vs. PowerCLI. Here are some questions to starte with. I appreciate adding any other aspects to connsider:

1. Does PowerCLI update existing database records created using IP discovery? Or does it create new database records? 

2. How does creating CIs using PowerCLI script impact our license count?

3. What is the difference between VMWare Discovery and PowerCLI when it comes to completeness of data? Meaning does one tool provide more details than the other?

 

Thank you in advance.

 

1 ACCEPTED SOLUTION

OK, so if you are using OOTB vCenter discvorey, it will discover the VMWare VM's as Virtual Machine Instances. These VMI's get related to the associated Server CI's, so you will see two records for kind of the same entity - but they are slightly different. It sounds like you have already discovered the Server records for some of these and last I heard, the licenses model counts either the VMI or the server  but not both - so if you have already discovered the Server record, then the VMI should not consume any further SU count. Of course, that assumes that the relationship between the records has been discovered, which will happen if you are using OOTB discovery on these.

 

If you want to use PowerCLI to create your own integration, you will have to make sure to create the correct recods on the correct classes etc. In order to maximise the chance of updating rather than creating new records, you would want to use Robust Transform to leverage IRE - pretty much how the Service Graph connectors work.

 

vCenter discovery works pretty well OOTB, so I'd recommend sticking with that. If you do find that you are getting duplicate records, you might jsut need to look at the identification rules on the relevant classes to see if you can match them up in a different way.

View solution in original post

6 REPLIES 6

David104
Tera Guru

Are you talking about writing your own integration? PowerCLI is a just a command line interface to the vCenter API, so from that perspective, the completeness of data comes down to what data you query.

 

With regard to updating existing records vs creating new ones, this will come down to how you build the integration. In general, you should use the IRE when creating any kind of integration into the CMDB to ensure that the identification can take care of update/create for you.

 

Keep in mind also that the OOTB vCenter discovery is already creating the valid relationships between various CI classes (ESX Host, Datastores, Clusters, Virtual Machines etc), so there could be quite a bit of effort in re-creating that.

 

The other key capability of the OOTB solution is the vCenter Event Collector which will process vCenter events in clost to real time so that changes in vCenter are reflected in your CMDB almost immediately - for example, update the host relationship for a vmotion event, or create a new CI as soon as a new resource is created.

 

The licensing question I'm not sure about, but from an OOTB perspective, my understanding is that you pay for either the 'Virtual Machine Instance' OR the related 'Server' CI (which also get related to each other via OOTB discovery). Therefore, if you are already discovering the Server CI, you may already be consuming a license. Of course, licensing questions are best answered by a ServiceNow representitive, and I really do not know if the CI's created from a custom integration would consume a subscription unit.

Thank you @David104 for the quick response. To clarify our situation further, we have collected some data about the VMs hosted on VMWare from SCCM, IP discovery, and integration with Dynatrace using Service Graph Connectors.  Now in order to complete the data and links between the CIs, we wanted to know how will VMWare Discovery or PowerCLI (Powershell scripts) will behave. Will either option create new records for the existing CIs, or will it match them and just add the missing data and links between them? Because our understanding is that new server CI records means additional licenses consumed, so we are trying to avoid additional cost. 

Thanks again. 

Thank you @David104  for the quick response.

 

To clarify further, we have captured some virtual machine data running on VMWare using SCCM, IP discovery, and Dynatrace using Service Graph Connectors. Now we want to refresh and compliment the data using either VMWare Discovery or PowerCLI (PowerShell Scripts that we are already using for other reporting needs). So our questions above were related to how will, either of these options, behave while fetching the data from VMWare VCenter, will they be able to match existing servers in CMDB, and just compliment missing data and links, or will it create new server records in new tables?  

Thanks again. 

OK, so if you are using OOTB vCenter discvorey, it will discover the VMWare VM's as Virtual Machine Instances. These VMI's get related to the associated Server CI's, so you will see two records for kind of the same entity - but they are slightly different. It sounds like you have already discovered the Server records for some of these and last I heard, the licenses model counts either the VMI or the server  but not both - so if you have already discovered the Server record, then the VMI should not consume any further SU count. Of course, that assumes that the relationship between the records has been discovered, which will happen if you are using OOTB discovery on these.

 

If you want to use PowerCLI to create your own integration, you will have to make sure to create the correct recods on the correct classes etc. In order to maximise the chance of updating rather than creating new records, you would want to use Robust Transform to leverage IRE - pretty much how the Service Graph connectors work.

 

vCenter discovery works pretty well OOTB, so I'd recommend sticking with that. If you do find that you are getting duplicate records, you might jsut need to look at the identification rules on the relevant classes to see if you can match them up in a different way.