Configuration & Administration

Expand all | Collapse all

Setting up for monitoring vSphere 6.0

  • 1.  Setting up for monitoring vSphere 6.0

    Posted 05-16-2018 04:05 PM

    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

  • 2.  RE: Setting up for monitoring vSphere 6.0

    Posted 06-29-2018 07:58 PM
    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


  • 3.  RE: Setting up for monitoring vSphere 6.0

    Posted 07-02-2018 10:09 AM
    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

  • 4.  RE: Setting up for monitoring vSphere 6.0

    Posted 08-16-2018 04:08 PM
    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