TECHZEN Zenoss User Community ARCHIVE  

Setting up for monitoring vSphere 6.0

Subject: Setting up for monitoring vSphere 6.0
Author: Eric Ward
Posted: 2018-05-16 17:05


We are hitting a wall getting our vSphere monitoring to model.

Specifically, I believe the issue may be around these parameters.   Does anyone have some experience?

zVSphereEndpointHost – where should this actually point? 'Hostname or IP used to connect to vSphere Endpoint'  - we have the server listed

zVSphereEndpointUser – which kind of account should I use?  'User used to connect to vSphere Endpoint' – we entered one of our own accounts


Eric Ward
Sys Admin
Restaurant Technologies
mendota heights MN

Subject: RE: Setting up for monitoring vSphere 6.0
Author: Jay Stanley
Posted: 2018-06-29 20:58

Are you using the ZenPacks.zenoss.vSphere ZenPack?

If so, the endpoint should be the IP (or hostname if resolvable) of the vSphere Center (Or ESX host if a stand alone)

User can be a read-only, as long as it has access to the API, metrics and can see everything


Subject: RE: Setting up for monitoring vSphere 6.0
Author: Eric Ward
Posted: 2018-07-02 11:09

Hi Jay,

We have tried many iterations and don't seem to have much luck.   We are working with 2nd level support and I will post the resolution here.

Eric Ward
Sys Admin
Restaurant Technologies
mendota heights MN

Subject: RE: Setting up for monitoring vSphere 6.0
Author: Eric Ward
Posted: 2018-08-16 17:08

We worked with support and found that by updating zVSphereModelMpLevel=3 we were able to successfully model.   Also, once we successfully modeled the vCenter we noticed some time out events.   We then updated the ZenPack to 3.7.2 and have had success.  We reverted the zVSphereModelMpLevel back to 0 and have been running well.   I am including the information from our ticket below.  Hope it helps:
The crucial change was setting zVSphereModelMpLevel=3. Here is an explanation of what this parameter does:

When a large vSphere endpoint is added (typically >1000 VMs, and especially
on systems where Impact is installed), it can take so long for zenhub to apply
the model that the applyDataMaps call times out, causing zenvsphere to
continuously retry the modeling of the device, but never succeed.

This issue is specific to initial modeling, that is, when the device has
no components in ZODB, so that thousands of components and relationships must
be created and indexed. Once the majority of the components exist in ZODB,
there are typically no such problems with applyDataMaps applying the same
model in the future, as it will be (mostly) unmodified from what is already

To work around this issue, a series of optimizations were added to the
vSphere modeler which, if the device has not yet been modeled,
post-process its results in several passes to break what would normally
be one large database transaction into several smaller ones, essentialy
building up the model incrementally, rather than all at once.

This is expected to take longer, because it is less efficient, but in practice,
it executes faster, on these large systems.

These optimizations are somewhat risky- it can leave the model in an incomplete
or inconsistent state. However, because zenvsphere always does a full remodel
when it restarts, or when it reconnects to vsphere, it is expected that
any model inaccuracies will be corrected the next time that occurs. Remember,
if enabled, these optimizations still only apply during the first time the device
is modeled. From that point on, everything is normal.

The "multi-pass" optimization is enabled by changing zVSphereModelMpLevel
to a value of 1, 2, or 3. Note that this variable must be in effect on the
newly added device before zenvsphere tries to model it, so you must either set it
on /vSphere, so your new device inherits it, or turn off zenvsphere, add the
device, set zVSphereModelMpLevel on the device, and then re-enable zenvsphere to
let it model that device.

In general it probably makes more sense to set it on the device class. If you are
concerned about leaving it enabled, you can always set it back to 0 after the
device is modeled successfully.

Suggested Next Steps

I suggest that you try this in your environment. The steps would be as follows:

First delete your existing vCenter device from RM
Set zVSphereModelMpLevel=3 on the vSphere device class (see attached screenshot)
Now re-add your vCenter device to RM
Check back in about 30-60 minutes to see if initial modeling has completed
If this is successful, you probably should switch zVSphereModelMpLevel back to 0 on the vSphere device class. This parameter is really intended only for the initial modeling, so it should not need to be enabled after that.

Eric Ward
Sys Admin
Restaurant Technologies
mendota heights MN

< Previous
Looking for solution for non-functioning hyperlinks
Cisco IP SLA threhsolds