Classification by device name

[Rick Mann]

I've seen a few forum topics around the Discovery of "Lights Out" components of a server (Red Hat or Windows), but I don't know that there is a documented solution. Here is what I'm seeing from Discovery:

- Discovery is able to discover a Linux server, but will also find the iLO that is setup for that server.
- The iLO is unable to be discovered, but a new CI is created for the iLO with the OS of GNU/Linux
- There doesn't appear to be any SNMP output in the ECC queue that can be used to classify the iLO.

Is there a way to simply not have discovery create a new CI if the name of the device contains "iLO"? I know that I could add IP exclusions for the iLO address, but this would really become a maintenance nightmare.

Thanks for any help.

Rick

[GlennIverson]

Rick,
Since the ILO (lights out) interface contains a MAC & IP address it will be discovered and a CI record will get created within the CMDB (if you are using the Service-now discovery tool).
Depending on what you are trying to accomplish with these ILO CI record and how much time you want to dedicate on this CI record that has very little value to the Service Management process
Example:
* No Incidents are assigned to an ILO port
- Difficult to managed from an automated monitoring tool (how much time do you spend on a maintenance port)
* No Change tickets are assigned since they are built into the primary computer
* No request are made to the ILO port (their purpose is for backend or diagnostic access only)
* The attribute is an Operational status value (up/down or Available/Not Available)

These ports DO support basic SNMP or SSH commands but you would need to build a custom probe. You also need to configure each ILO ports with the correct credentials. We did build a custom SNMP tool that would execute an SNMP get command, pulled back an SNMP variable that contained the Primary server address. We would do a match between the Primary port and the ILO port. The problem is managing the SNMP credentials on these ports is very time consuming. Managing changes on the and we found it have very little if not no value to the support teams.
How we manage the ILO ports in our environment
We assign a DNS naming standard on all ILO ports using the word "ILO (and primary server name). This allows us to quickly identify any or all ILO port within the CMDB. We deployed a simple filter that filters out any name with the word ILO in our Server view. We did create a view on our Enterprise CMDB view that displays any name with the word ILO. This allows our support teams to view the ILO's if…. They want to.
Conclusion
We have other higher priorities discovery/CMDB task to dedicate development/support hours then to spent time on these non (service management) CI Records

Glenn Iverson

[Rick Mann]

Glenn

Thanks for the info. I've made the same argument about iLOs that you stated in your post and I think the organization now understands.

So that I'm clear. You still allow discovery to create a CI record for the iLO, but have created default filters so that the records are not visible by default.

Thanks.

Rick

[jpd713]

Hi Rick, I also had a lot of trouble with iLOs and ProLiant servers in my Discovery environment. My issues seemed to come from the iLO default configuration of acting as an SNMP pass-through. That is, an SNMP query sent to an iLO is answered by the server.

Like Glenn suggested, if you can be sure all of your iLOs are named a certain way, that's probably the way to go - just add an SNMP Classifier to match on this naming scheme. I believe the default naming is "ilo" plus the server's serial number, so "iloea2d6f454k".

In my environment, there was too much variation to reliably classify based on the name - or anything else Discovery had available at this point. I eventually found CPQSM2-MIB::cpqSm2CntlrAgentLocation that returns an integer indicating where the SNMP response is coming from - the host OS or the iLO. Based on this, I could reliably distinguish between an iLO and the server it's attached to. In my case, I wasn't too interested in the iLOs, I was just trying to stop them from corrupting my Winserver CIs.

Here's what I did:

--Added SNMP MIBs CPQHOST-MIB and CPQSM2-MIB.
--Added walk to CPQSM2-MIB::cpqSm2CntlrAgentLocation to SNMP Classify probe.
--Updated classify sensor to check the new OID and set an "ilo" SNMP capability true when the result is 2, 3, or 4.
--Added a dummy (empty) classifier to run before the computer classifiers that checks my new ilo capability and just logs to the Discovery Log.

[pratiksha5]

Which table do you use for ILO device?