NMIS Virtual Machines - VMGuests not showing all hosts

 
1
0
-1

Hi again o/ more questions (smile)

I have added 5 ESX Hosts to NMIS:

The first node has been added completely - SNMPv2c has pulled interface, storage and VMGuests successfully from the host. Running ESX v5.1.

The remaining nodes do not appear to have pulled the VMGuests information. When I click on the VirtMachines tab there is nothing listed at all.

It's been a while but I'm very sure that SNMP was enabled the same way for each host. Interface and storage data has been retrieved successfully. At least one of the remaining hosts is identical in version, ESX v5.1, the others are v5.5.

I have tried deleting and re-adding the hosts, even in different orders, still the same results.

Is this likely a configuration issue with the ESX host SNMP, or a potential bug in NMIS?

 

Thanks for your help.

    CommentAdd your comment...

    2 answers

    1.  
      3
      2
      1

      Hello Again Hartleigh,

      You mention you receive some SNMP data from the remaining 5.5 and 5.1 hosts so SNMP the protocol is working OK.

      As the SNMP protocol appears to be working on all hosts and one of the hosts is producing the correct results it could be an issue with SNMP on the ESXi hosts themselves. They may not be returning the information due to configuration issues.

      A good debug in these situations is using the snmp tool :

      "Network Tools" >  "SNMP Tool"    then in the SNMP Tool select the node that works and enter this OID into the OID box: 1.3.6.1.4.1.6876.2.1.1.2  You should see the names of the guests.

      Try it on one of the other servers and see what result you get.  This should give you an idea of whether SNMP is working and what each ESX server is returning to you for the query in use.

      1. Hartleigh

        Hi Nick. Thanks for your reply. So these are the results that I get from my 1 working and 1 non-working hosts. Both running ESX v5.1. VMHost 1 - ESX v5.1 enterprises.6876.2.1.1.2.1 1.3.6.1.4.1.6876.2.1.1.2.1 GuestName enterprises.6876.2.1.1.2.2 1.3.6.1.4.1.6876.2.1.1.2.2 GuestName enterprises.6876.2.1.1.2.3 1.3.6.1.4.1.6876.2.1.1.2.3 GuestName enterprises.6876.2.1.1.2.6 1.3.6.1.4.1.6876.2.1.1.2.6 GuestName enterprises.6876.2.1.1.2.11 1.3.6.1.4.1.6876.2.1.1.2.11 GuestName enterprises.6876.2.1.1.2.14 1.3.6.1.4.1.6876.2.1.1.2.14 GuestName enterprises.6876.2.1.1.2.15 1.3.6.1.4.1.6876.2.1.1.2.15 GuestName enterprises.6876.2.1.1.2.16 1.3.6.1.4.1.6876.2.1.1.2.16 GuestName enterprises.6876.2.1.1.2.17 1.3.6.1.4.1.6876.2.1.1.2.17 GuestName VMHost 2 - ESX v5.1 enterprises.6876.2.1.1.2 1.3.6.1.4.1.6876.2.1.1.2 noSuchInstance Looking in to this noSuchInstance now.

      2. Hartleigh

        OK, the plot thickens. If I run snmpwalk from my PC to the same two hosts tested above, results are returned in both instances. VMHost 1 c:\Temp\snmpwalk>SnmpWalk.exe -r:10.50.50.9 -v:2c -c:"community" -csv -os:.1.3.6.1.4.1.6876.2.1.1.2 -op:.1.3.6.1.4.1.6876.2.1.1.3 .1.3.6.1.4.1.6876.2.1.1.2.1,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.2,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.3,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.6,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.11,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.14,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.15,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.16,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.17,OctetString,GuestName VMHost 2 c:\Temp\snmpwalk>SnmpWalk.exe -r:10.50.50.7 -v:2c -c:"community" -csv -os:.1.3.6.1.4.1.6876.2.1.1.2 -op:.1.3.6.1.4.1.6876.2.1.1.3 .1.3.6.1.4.1.6876.2.1.1.2.7,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.8,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.18,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.19,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.20,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.21,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.25,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.26,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.29,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.31,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.33,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.34,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.35,OctetString,GuestName .1.3.6.1.4.1.6876.2.1.1.2.36,OctetString,GuestName This is beginning to look like a bug in NMIS.

      3. Hartleigh

        Oh wait, I see it now. The OID results start from .1.3.6.1.4.1.6876.2.1.1.2.7 and I guess that NMIS is looking for .1.3.6.1.4.1.6876.2.1.1.2.1.

      CommentAdd your comment...
    2.  
      1
      0
      -1

      Hartleigh,

      Thanks for looking into this, NMIS will be handling the index not starting at .1 we are using the standard calls for this.

      There are a few things this could be, if it works from one computer and different results from another that might be SNMP Views configured in the ESXi server preventing access to the MIB.

      The best way to verify this is to run a collect with debug from the NMIS server to the ESXi server with the problem and we will see very quickly what is happening.  We can use the The NMIS Support Tool (that is a link).

      Can you please run the following command:

      /usr/local/nmis8/admin/support.pl action=collect node=ESXISERVER

      That will collect the information we need into a ZIP and you can email that ZIP to support@opmantek.com

       

      Regards

       

      Keith

        CommentAdd your comment...