8 Replies Latest reply on Oct 1, 2009 8:52 AM by kupjones

    Add esx 4 to orion NPM


      I've problems adding a new esx4 to orion NPM.

      I've several esx 3.5 added to orion and they work perfectly, list all machines and resources.

      Last week i add my new esx 4 server and i notice something diferent, snmp is no longer as in esx 3.5 i configur the new snmp on esx4 and already have the node listed on orion but i can't see any of the virtual machines on it as i saw in esx 3.5.

      Also the esx3.5 is recognized as esx machine type and the esx4 is as net-snmp - Linux

      Thoose any one knows how to solve this.

      the next print's show the esx 3.5 with all vm machines and the esx4 without anything.



      Thanks for the help

        • Re: Add esx 4 to orion NPM

          Please see the existing thread on this issue. Unfortunately, there doesn't appear to be any solution currently.

          They think it will be fixed in 9.6, but (and i quote) their "rules around accounting don't allow [them] to provide specific dates that far in advance."

          VMware vSphere 4 (ESX 4), can we monitor them like VI3's ESX 3.x?

          We've tried just about everything we could think of on our end to get this working but to date have had no luck.

          1 of 1 people found this helpful
          • Re: Add esx 4 to orion NPM

            I had just asked this question as well.  It seems that NPM does not currently support ESX 4.x.  It is in the works BUT there is no timeframe as to when it will.

            • Re: Add esx 4 to orion NPM

              These threads are correct.  VMWare is no longer populating their MIB's as they did in ESX 3.5.  To address this, we are going to have to change our method of getting to the data and use their API.

                • Re: Add esx 4 to orion NPM

                  Brandon, the vSphere Basic Admin indicates that the HOSTD process on ESX 4 exposes a new set of MIBs that appear to be fully populated with the data that was originally populated into the HOST-RESOURCES MIB. (see page 55 in the doc http://www.vmware.com/pdf/vsphere4/r40/vsp_40_admin_guide.pdf).

                  So the question is -- is it really necessary to go after the API (uggg)??? 

                  An alternative given by VMware is to enable Net-SNMP and setup a proxy to HOSTD -- which I consider to be a hokey solution.


                  I've already banged on our VMware channel SE about the abandonment of Net-SNMP -- something i consider to be be very short-sighted.

                    • Re: Add esx 4 to orion NPM

                      The problem with using their "hokey" solution is that some of the important OIDs including the VM's interfaces bytes sent and received were removed and no new OIDs where added in their place.

                      John Taylor

                        • Re: Add esx 4 to orion NPM

                          BTW, "hokey" is a technical term.


                          Yes, they no longer expose the vnic interface statistics.  VMware really mucked this one up.

                            • Re: Add esx 4 to orion NPM

                              Here is Texas, hokey is a formal part of everyday speech.  Since we were going to have to change our method to gather this data we choose the API as it will allow us access to a lot more data if we choose to use it in the future

                                • Re: Add esx 4 to orion NPM

                                  Choosing the API road is unfortunate, as I consider programming API's to be vastly inferior mechanisms for gathering system performance data -- not to mention being much more susceptible and sensitive to infrastructure variance.

                                  Question:  Why not deliver both?   Build vSphere models that use the new SNMP MIBs, then stay on track with the API scheme?  I see little downside to the first as it leverages existing SW development knowledge and will likely deliver a much quicker solution to your customers? 

                                  Just curious why completely abandoning SNMP is the right choice.