Highlighted
DaddyW123
1 Copper

ESXi issues on inventory

I've run through quite a few how-to's here and throughout the web and still having some issues.

We are running pretty much all ESXi (NOT ESX).  Most hosts are 4.1 but we are also in the process of testing 5.

on my ESXi 5 test box, I've got OMSA installed using the vSphere CLI and the following:

esxcli --server <host> software vib install -d /var/log/vmware/OM-SrvAdmin-Dell-Web-6.5.0-542907.VIB-ESX50i_A02.zip

and confirmed it works by using a windows box, installed Open Manage Server Admin Web, and am able to remotely access OMSA to see everything - however, I had to check the box to ignore certificate warnings when logging in.  Without that option checked, login failed with a certificate error.

Next - Followed procedures for SNMP Config via CLI:

vicfg-snmp.pl --server <host> --username root --password <password> -t <target>@162/<Community Name> -c <Community Name>

also enabled it with -E argument.  Confirmed looks right with --show

OME did pull the server in during discovery but still as unclassified VMware Server.  Discovery range does have SNMP configured with the correct Community names, and WS-MAN is using the root credentials.

When running the troubleshooting tool, SNMP does go through, but it only pulls MIB-II (System Name) and VMWare (Product Version) - but it does NOT pull the OMSA version, which I saw in other troubleshooting threads that it should be.

In other threads, they mentioned editing the etc\snmp\snmpd.conf file... however the snmp folder doesn't even exist, and I believe that is because this is ESXi, rather than ESX.

I'm now at the end of all the troubleshooting I've found, so I need to know where to go from here.  I haven't installed the OMSA client on any of my esxi 4.1 hosts yet because it looks like that's a different download and procedure than shown above for 5... but I have a feeling the results will be similar.

Oh yeah, and I have restarted the host.  So any ideas?

0 Kudos
4 Replies

Re: ESXi issues on inventory

what does WS-Man return on the troubleshooting tool?

are you bypassing the certificate on the discovery as well? (wsman)

sounds like you are getting the vmware information (snmp) but not the inventory information(ws-man) for esxi.  

you are correct.  snmpd.conf is for ESX

0 Kudos
DaddyW123
1 Copper

Re: ESXi issues on inventory

WN-Man troubleshoot returns Connected, WSMAN Profiles found on remove device are: Job Control; Software Update... a total of 19 profiles.  And the test has an option for Ignore Certs, it's checked by default, and it is grayed out so I can't uncheck it anyway.

Discovery doesn't seem to have specific check to ignore certs.  There is a section on "Secure Mode", but that is not checked.

However, I did just notice that the port entered by defult in discovery is 623, but in troubleshoot tool the defult port it's using for that is 443.

I don't know if this is relevent because I currently have the firewall turned off inside vSphere host configuration (at least my vmware guy told me he turned it off), but I'm I'm still learning VMWare and Linux in general.  So I don't know if there is some place else I need to open the ports.

0 Kudos
DaddyW123
1 Copper

Re: ESXi issues on inventory

Looks like I may have it - I checked off the option for "Secure Mode", and the port automatically changed to 443.  Then I selected both sub options for "Skip Common name check" and "Trusted Site", but did not enter anything in the "Certificate File".  Re ran the discovery and it appears as though it's pulled everything this time.

Normally I don't like changing two things at once (don't know which variable fixed it), but I think it was the "Trusted Site" option that was the kicker here because when you select that, it wont let you enter a cert file.  But just out of curiosity - what do both of these options do specifically?

By the way, thanks for the help.  I don't think I would have thought to try that option.

0 Kudos

Re: ESXi issues on inventory

the Common name check -  ignores if the Certificate name does not match the host name (technet.microsoft.com/.../dd891009.aspx)

the Trusted site check -  automatically assumes the certificate is trusted without checking.  (applies to self signed certificates)

0 Kudos