vCenter Discovery - Get custom attributes in vSphere

[gustavo_and]

Hi,

Our organization is looking to bring all VMs that are managed in vSphere into our CMDB. For data consistency we have created custom attributes in vSphere to normalize the information no matter what kind of VM we are looking at. We would like to bring said attributes in the CMDB.

Now the question is how do i bring the attributes from vCenter/vSphere. I've looked through ServiceNow Documentation about Discovery/probes/patterns.

Now it seems that vCenter Discovery is particular on it's on way,  so it is very unclear if bringing custom attributes is actually faisable and if so how do you configure to get the end result?

Appreciate any input!

[Selva Arun]

To bring custom attributes from vSphere into the CMDB using Discovery Pattern Extensions, you can follow these steps. Extensions allow you to modify or enhance existing patterns without directly customizing them, ensuring easier upgrades and maintenance.

Steps to Use Extensions for vSphere Discovery Patterns

1. Navigate to the Discovery Patterns Module
• In the ServiceNow instance, go to Pattern Designer → Discovery Patterns.
• Search for the vSphere Discovery pattern you want to extend (e.g., "vCenter Discovery").
2. Create a New Extension
• Open the selected pattern.
• In the Extensions section, click New to create a new extension.
• Provide a descriptive name for the extension (e.g., "vSphere Custom Attributes").
• Save the extension, and it will appear in the list of extensions for the pattern.
3. Design the Extension in Pattern Designer
• Click on the newly created extension to open it in the Pattern Designer.
• Add a new step to query the vSphere API for custom attributes.
• Use the HTTP Get Call operation or any other relevant operation to interact with the vSphere API.
• Ensure you have the correct API endpoint and credentials configured.
4. Parse the Custom Attributes
• Add a step to parse the response from the vSphere API.
• Use operations like Parse Variable or Set Parameter Value to extract the custom attributes and store them in temporary variables.
5. Map the Custom Attributes to CMDB Fields
• Add a step to map the parsed custom attributes to the appropriate fields in the CMDB.
• Use the Set Parameter Value operation to assign the custom attributes to the corresponding CMDB fields.
6. Test the Extension
• Use the Debug option in the Pattern Designer to test the extension.
• Provide the IP address or hostname of a vSphere instance and verify that the custom attributes are being retrieved and mapped correctly.
7. Activate the Extension
• Once the extension is tested and validated, save and activate it.
• The extension will now run as part of the discovery process for the selected pattern.
8. Run Discovery and Validate
• Run a discovery schedule that uses the extended pattern.
• Check the CMDB to ensure the custom attributes are being populated correctly.

Key Considerations

• Ensure you have the necessary permissions to access the vSphere API and retrieve custom attributes.
• Always test the extension in a non-production environment before deploying it to production.
• Extensions are executed in the order they are listed. If there are conflicting values, the last extension to run will take precedence.

Supporting Documentation

1. ServiceNow Documentation: Modify Patterns Using Extensions
   https://www.servicenow.com/docs/bundle/vancouver-it-operations-management/page/product/service-mappi...
2. ServiceNow Documentation: Discovery Patterns Overview
   https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1612162
3. VMware vSphere API Documentation
   https://developer.vmware.com/apis

By using extensions, you can enhance the vSphere Discovery process to include custom attributes without directly modifying the base patter

If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'** and **'Accept it as a Solution'**? This will help other community members who might have the same question find the answer more easily.

Thank you for your consideration.

 Selva Arun

[Kieran Anson]

Please don't post AI generated content.

[Doci1]

Aa Kieran wrote, tags are imported into [cmdb_key_value] table.

[Tyson Elder]

Has anyone actually done this yet?

From my brief investigation - tag management in vmware isn't the best and so many technical teams move to custom attributes as 'tags' against VMs. I'm sure this wouldn't be tooo hard - but dealing with probes is such a pain. 

[gustavo_and]

Hey Tyson,

So turns out that vCenter discovery is very distinct : https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0813327.

I was told by ServiceNow support that what I was looking for was not feasable (although I think the agent just didn't bother asking any engineer).
I gave up and went with the following approach:

1. Set the discovery of vCenter VMs. This will bring your VMs into the CMDB cmdb_ci_vmware_instance table.
2. Create the custom fields on the cmdb_ci_vmware_instance table.
3. Then I set up a scheduled import that would execute a powershell script to get the custom attributes from vCenter (not the best when it comes to performance, so if you have a big VM dataset, then I would suggest splitting the imports somehow).
   
   1. I noted the VM that hosts our MID Server dedicated to CMDB discovery/SGC integrations and I asked the infra team to install the VMware.PowerCLI module on the VM.
   2. I asked the infra team to install the VMware.PowerCLI module on the VM to enable vCenter powershell commands.
   3. Create the ps1 file on the ecc_agent_script_file table.
   4. Created an action on workflow studio for the powershell execution.
   5. Created a script include to execute the action and load data into import set table.
   6. Created a "Load by Script" data source that calls the data load method from the script include.
   7. Create the Scheduled Data Import.
4. Using a classic transform map, I map the custom attributes from vCenter to the target custom fields. I use the source ID field to the target object_id as Coaslesce (it was accurate when testing the case where a VM was deleted and restored with a backup in vSphere. The object_id is not kept in these scenarios so using VM name was not accurate).

Hope this can help you somehow. Let me know if you have any questions!