Split the vCenter discovery job so we should have a new job only for the vCenter storage topology

Split the vCenter discovery job so we should have a new job only for the vCenter storage topology

We should split the vCenter Topology job into 2 different jobs due to the high amount of CIs that it can report on big vCenter deployments. 
For a 7000 VM deployment, it will create an 800+ MB Communication log with results included and 600k CIs out of which 320k CIs are storage related.
We need a new discovery job which reports only the storage topology of a vCenter, something like vCenter Storage Topology by VIM.

The current job is used and preferred as the customer will have only one set of credentials but this will bring too many CIs in one bulk. Even splitting the bulk per datacenters isn't always good as the VMware topology is specific and difficult to identify. The ESX approach isn't too used as it implies defining the same VIM credentials on hundreds of ESX servers.

Splitting the current vCenter job into 2 new jobs will allow for a better discovery schedule, a more granular one. We would use the current scripts but they will have to model a slightly different topology. For the classic job (the current vCenter topology job) we should avoid modeling the storage CIs. For the new job (vCenter topology) we should model only the storage CIs and the related CIs needed for reconciliation (root_containers, etc).

We already have similar ERs submitted on this discovery flow. Currently, we are pushing the limits of the probe and server with everything discovered in one single job.

Similar ERs performance related:

 

Tags (3)
4 Comments
Micro Focus Expert
Micro Focus Expert
Status changed to: Waiting for Votes

Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team

Acclaimed Contributor.. Dima Gomel Acclaimed Contributor..
Acclaimed Contributor..

I would suggest implementation of the feature as a parameters for current job. IT will give an option for the customer with small VC deployments to run the same way it was before, and for big deployments, the customer could  just create a copy of the original discovery job and restrict this either for Storage, Network or Compute perspective with a parameter.

Micro Focus Expert
Micro Focus Expert

@Dima Gomel, we already have such an ER https://softwaresupport.softwaregrp.com/group/softwaresupport/search-result/-/facetsearch/document/LID/QCCR1H125480 but the problem is that we may have UCMDB users who need that storage information for billing purposes. So either you disocvery the storage topology or either you don't because it's the same job.
Exluding LUNs is still not the best option. The storage topology involves the CITs: LUN, fchba, icsci_initiator, logical_volume, disk_device, networkshare or vmware_datastore.
From my past experience, the storage CIs can be somewhere around 30-50% of the total CI count from the result vector.

RohitSS Honored Contributor.
Honored Contributor.

Hi ,

We are facing an issue for one of the vCenter appliance, where VMware VirtualCenter Topology job by VIM is not working. New VMs are not getting populated. Error thrown is "Job was running more than 2700000 msec"

We tried with default value 900000 msec but  it failed with Fatal Error "Job was running more than 1800000 msec"

and then increased it to 1800000 (Max. execution time) on discovery adapter but again it failed with Fatal Error "Job was running more than 1800000 msec"

We again then increased Max. execution time to 2700000 on discovery adapter but again it failed with Fatal Error "Job was running more than 2700000 msec"


VMware Vcenter.png

 

Any workaround to resolve the issue ?

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.