vmware/vcenter probe warnings/errors how to resolve ?

[brukasmj]

Hello everybody,

This week i started with the discovery of my companies vcenter in order to see what is being discovered and what will be the relationships etc.

These are the facts and steps i took:

• Instance is running Geneva Patch 7
• vcenter is running on version 5.5 update 3
• Most of the esx hosts are running version 5.1.0 and higher
• vcenter is running on windows 2012
• Created Windows and vmware vcenter credentials
• Ran a discovery on the host on which windows and vcenter are running
  • port scanning, classification, identification for windows successfull
• For the vmwareprobe/vmwarecenterprobe
  • output processed
  • Input > error shows up
  • This is the error:
  • Payload attachment exceeds the limit of 5242880 bytes set by system property com.glide.attachment.max_get_size.
    • Before this one i had this error: Payload length 5671972 exceeded limit of 5000000
    • corrected by changing the properties for this parameter mid.discovery.max_payload_size   to -1

1. So the question is how to resolve the process so that the data is being discovered and the error is being fixed ?
   1. Should i go ServiceNow KB: PRB633324: Discovery sensor unable to process ecc_queue input with an attachment grea...
   2. Or are both workarounds dangerous for the vcenter host or the instance ?
2. Second question: is how is the sensor working, is it pushing data based on results from the attachments into memory ?
3. Third question: is this the right approach to make the relationships visible between vcenter > esx(i) hosts > vm's ?

Appreciate to get some help here ?

All have a great weekend

[jake_mckenna · Accepted solution]

I have run into this with deployments who have a large vCenter payload. Following the KB you attached is exactly what I did. For my testing i went up to a 8.5mb size and was able to get the results. This is something we obviously need to test on a per instance basis, but the reason for the limit is to stop you from overloading the instance and potentially making it crash. If you try to load a large file from any SOAP data source you should get the same error. Any payload over the size of the field itself will be loaded as an attachment to avoid missing data during processing, and read by the instance when found.

For your 3rd questions this is the best way to capture the relationships. This probe/sensor will give you all you vCenter relationships and also enable in the background a business rule to link that information with the cmdb_ci_server records that are you guests so you have a complete picture.

[brukasmj]

Thanks Jake, but how to determine what size fits best. I really don't have a clue. Our vcenter environment seems to be big, it is covering all esxi locations from the whole globe within my company

[brukasmj]

Jake,

Here are the screencopies of what i did in the gui of the saas instance. Here are the screencopies:

1 In the Discovery Status area, the interface was showing this error

2 When checking the details i saw that it is limited by the number of bytes as printed in the screen copy

3 To check the setting i went to the filter navigator:

4 I added this property, as it was not in the list:

When opening the attached number 1 image, i found the payload.txt with a size of 5.7 MB

So the property is liming to process the data. I changed this to 7MB and the data is being processed.

So where can i find a measurement when the instance will be overloaded by changing this setting ?

Thanks again Jake, hopefully this information will be usefull for other community members as well

[jake_mckenna]

For detecting memory issues I think there is no real golden rule as far as what the limit is. You can view the diagnostic/Performance dashboards, but that might still be a challenge. There should also be mention in logs of memory allocations hitting a high point so we might be able to be diligent and pull logs from a tested discovery and parse out any memory issues. http://wiki.servicenow.com/index.php?title=Viewing_System_Logs#System_Logs