Server Management - Systems Insight Manager
cancel
Showing results for 
Search instead for 
Did you mean: 

HP SIM 6.0 - blades in wrong place, servers duplicated

ChristianWickham
Frequent Advisor

HP SIM 6.0 - blades in wrong place, servers duplicated

We installed HP SIM 5.1 about 18 months ago and then left it unmanaged for a while. Now we have upgraded to HP SIM 6.0 and started to use the system.
Some strange issues have appeared;
* Viewing our blade chassis, some slots appear empty, and the blade that is in that slot appears as a standalone server. All blades have the same OS (ESX4) and HP agents and configuration - how can I tell SIM that the blade is in the chassis and not standalone?
* Some servers have been detected twice, once as their serial number (with no IP address) and one as the hostname and IP address. Then the iLO is shown as inside the device that is just the Serial number - how can I resolve this?
* Some iLOs are showing that they are inside two servers at the same time - three even state that they are inside the same server twice, but the "parent" server only appears once. How can I clean this up?

Is there an easy way to clean this up without loosing all the historical data about these systems?
4 REPLIES
LakshmiBN
Advisor

Re: HP SIM 6.0 - blades in wrong place, servers duplicated

Can you please check the serial number and UUID values are same for the servers thats has been detected twice.
Also try re-discovering OA first, followed by servers and then iLO IP. This will help blades to get associated with enclosure and iLO to server.
Are the servers moved across enclosures after upgrading SIM to 6.0?
ChristianWickham
Frequent Advisor

Re: HP SIM 6.0 - blades in wrong place, servers duplicated

We haven't moved any blades to different slots or different enclosures since upgrading to SIM 6.

Can you please go through the process of re-discovering? I have been discovering the whole subnet for each datacentre and server room - do we need to discover individual hosts to force the OA to be discovered first?
The OAs and iLOs are on the same subnet, the blade OS (ESX4 & Linux 5.3) are on a different subnet (the same as SIM and all other servers).

The record that shows the serial number of the server has no information in the properties, just the serial number. The serial numbers are for HP servers which are otherwise detected in SIM - I have suspended monitoring as the records have no IP, but some of the iLOs report that they are inside the servers that are just a serial number. If I delete these serial number only records, will I loose information/history on the iLO devices or will they re-align themselves to the correct servers?

Thanks
LakshmiBN
Advisor

Re: HP SIM 6.0 - blades in wrong place, servers duplicated

What historical information on serveres are you looking for? Have you installed any other plugins? The nodes without IP address wont be managed. I dont think any data will be associated with it. You can delete the nodes with serial number and without IP. Just cross verify the serial number from the actuall server node which is having IP with the serial number named node. Both the nodes serial number and UUID should match.
Meaning the node which is associated with iLO and the node with IP address should match.
ChristianWickham
Frequent Advisor

Re: HP SIM 6.0 - blades in wrong place, servers duplicated

I have followed your advice, deleted the duplicated and errored and serial number only devices, then performed a re-discover in the order of Blade OA, Server IP (where SMH is installed), then iLO for servers where the iLO was not detected through the server IP, or if the server IP is in a DMZ/unroutable location but the iLO is contactible by SIM.

This eventually detected everything again correctly, the only machines that were detected as a serial number without a name and IP ended up being just DMZ hosts, and I changed the label name to match the real hostname and everything then worked out fine.

The historical information we wanted was related to ASR reboots and times when systems were unavailable, as we had been diagnosing as a part of customer advisory c01802766 (iLO 1.81 and lower causing ASR with eventlog entry NetFN 0x4, command 0x2D timed out)